Manage Postgres parallel plans when estimating row count

[troopa81]

Description

Fixes #37342, follows #32114

Previous PR wasn't dealing with possible parallel plan when estimating count. This one use a simpler SQL request where the number of rows is contained in the top node whether it is parallel (sum up the children gather node count) or not

[saberraz]

Does this need to be backported?

[saberraz]

@wonder-sk would it be possible to review this PR?

[troopa81]

Does this need to be backported?

for 3.14 yes, for 3.10 I believe that it was proposed to wait & see if everything is fine in 3.14 before backporting.

[wonder-sk]

Hmm... what do you think of using this method (parsing execution plan from JSON) only with views - and for tables use the old method of reading the estimated counts directly from pg_class? The reliance on execution plan and its JSON is a bit scary to me and I would expect it can break when there are changes to the planner or to the output format...

[troopa81]

Hmm... what do you think of using this method (parsing execution plan from JSON) only with views - and for tables use the old method of reading the estimated counts directly from pg_class?

It would cost an extra request to check if mQuery is a view or a table (calling relkind)

The reliance on execution plan and its JSON is a bit scary to me and I would expect it can break when there are changes to the planner or to the output format...

I understand your concerns but the proposed version relies on the number of rows of plan top node, so the planner could change but you'll always get an estimated row count in top node. As for the format, it could indeed change but as it's kind of a API breaking change, I would say it shouldn't happen often (never?). And if it happens we would have to fix the view part anyway.

[wonder-sk]

Okay - let's leave it like this and hope PostgreSQL won't change the syntax in the future... or make the texts translatable :-)

[troopa81]

@wonder-sk Would you mind merging it?