Store the total number of plans in PlannedStmt.

[yrashk]

Extensions that use planner/executor hooks can't precisely pre-allocate memory for data structures mirroring the plan as the number of plan nodes is unknown.

This information is effectively collected in the standard planner in the node ID counter but was discarded at the end. This change preserves this information.

[einhverfr]

I am assuming that the performance implications of this are minor and plan-time only.

Nonetheless if we want to submit this upstream we will definitely need to benchmark it to prove that is the case.

[postsql]

why not unsigned int ?

also, let's name it plan_nodes_count or similar as total_plans could indicate that there are potentially multiple plans.

[yrashk]

Makes a lot of sense, will address shortly!

[yrashk]

src/backend/nodes/gen_node_support.pl doesn't support unsigned int:

could not handle type "unsigned int" in struct "PlannedStmt" field "plan_nodes_count"

[danolivo]

Extensions that use planner/executor hooks can't precisely pre-allocate memory for data structures mirroring the plan as the number of plan nodes is unknown.

This information is effectively collected in the standard planner in the node ID counter but was discarded at the end. This change preserves this information.

For me, it may be resolved by just walking through the plan nodes: Some people want to take into account only nodes from the plan, while others want to count CTEs and Subplans nodes, too. It depends on the purpose.
I think, more general solution could be to add a 'List *extended_data' field into PlannedStmt where any extension could store information and reuse it during execution phase.