Store the total number of plans in PlannedStmt.
#1
Conversation
yrashk
force-pushed
the
planned-stmt-total_plans
branch
from
336fb9c to
9d21e62
Compare
|
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. |
src/include/nodes/plannodes.h
Outdated
| ParseLoc stmt_location; /* start location, or -1 if unknown */ | ||
| ParseLoc stmt_len; /* length in bytes; 0 means "rest of string" */ | ||
|
|
||
| int total_plans; /* indicates the number of plan nodes in the statement */ |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Makes a lot of sense, will address shortly!
There was a problem hiding this comment.
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"
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.
yrashk
force-pushed
the
planned-stmt-total_plans
branch
from
9d21e62 to
68d38d2
Compare
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. |
4 participants
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.