Update executor documentation for run-time partition pruning
With run-time partition pruning, there is no longer necessarily an executor node for each corresponding plan node. Author: David Rowley <david.rowley@2ndquadrant.com>
This commit is contained in:
parent
c058fc2a2b
commit
86a4819f69
@ -45,13 +45,21 @@ Plan Trees and State Trees
|
|||||||
|
|
||||||
The plan tree delivered by the planner contains a tree of Plan nodes (struct
|
The plan tree delivered by the planner contains a tree of Plan nodes (struct
|
||||||
types derived from struct Plan). During executor startup we build a parallel
|
types derived from struct Plan). During executor startup we build a parallel
|
||||||
tree of identical structure containing executor state nodes --- every plan
|
tree of identical structure containing executor state nodes --- generally,
|
||||||
node type has a corresponding executor state node type. Each node in the
|
every plan node type has a corresponding executor state node type. Each node
|
||||||
state tree has a pointer to its corresponding node in the plan tree, plus
|
in the state tree has a pointer to its corresponding node in the plan tree,
|
||||||
executor state data as needed to implement that node type. This arrangement
|
plus executor state data as needed to implement that node type. This
|
||||||
allows the plan tree to be completely read-only so far as the executor is
|
arrangement allows the plan tree to be completely read-only so far as the
|
||||||
concerned: all data that is modified during execution is in the state tree.
|
executor is concerned: all data that is modified during execution is in the
|
||||||
Read-only plan trees make life much simpler for plan caching and reuse.
|
state tree. Read-only plan trees make life much simpler for plan caching and
|
||||||
|
reuse.
|
||||||
|
|
||||||
|
A corresponding executor state node may not be created during executor startup
|
||||||
|
if the executor determines that an entire subplan is not required due to
|
||||||
|
execution time partition pruning determining that no matching records will be
|
||||||
|
found there. This currently only occurs for Append and MergeAppend nodes. In
|
||||||
|
this case the non-required subplans are ignored and the executor state's
|
||||||
|
subnode array will become out of sequence to the plan's subplan list.
|
||||||
|
|
||||||
Each Plan node may have expression trees associated with it, to represent
|
Each Plan node may have expression trees associated with it, to represent
|
||||||
its target list, qualification conditions, etc. These trees are also
|
its target list, qualification conditions, etc. These trees are also
|
||||||
|
Loading…
x
Reference in New Issue
Block a user