50.6. Executor#
Theexecutor takes the plan created by the planner/optimizer and recursively processes it to extract the required set of rows. This is essentially a demand-pull pipeline mechanism. Each time a plan node is called, it must deliver one more row, or report that it is done delivering rows.
To provide a concrete example, assume that the top node is aMergeJoin node. Before any merge can be done two rows have to be fetched (one from each subplan). So the executor recursively calls itself to process the subplans (it starts with the subplan attached tolefttree). The new top node (the top node of the left subplan) is, let's say, aSort node and again recursion is needed to obtain an input row. The child node of theSort might be aSeqScan node, representing actual reading of a table. Execution of this node causes the executor to fetch a row from the table and return it up to the calling node. TheSort node will repeatedly call its child to obtain all the rows to be sorted. When the input is exhausted (as indicated by the child node returning a NULL instead of a row), theSort code performs the sort, and finally is able to return its first output row, namely the first one in sorted order. It keeps the remaining rows stored so that it can deliver them in sorted order in response to later demands.
TheMergeJoin node similarly demands the first row from its right subplan. Then it compares the two rows to see if they can be joined; if so, it returns a join row to its caller. On the next call, or immediately if it cannot join the current pair of inputs, it advances to the next row of one table or the other (depending on how the comparison came out), and again checks for a match. Eventually, one subplan or the other is exhausted, and theMergeJoin node returns NULL to indicate that no more join rows can be formed.
Complex queries can involve many levels of plan nodes, but the general approach is the same: each node computes and returns its next output row each time it is called. Each node is also responsible for applying any selection or projection expressions that were assigned to it by the planner.
The executor mechanism is used to evaluate all five basic SQL query types:SELECT,INSERT,UPDATE,DELETE, andMERGE. ForSELECT, the top-level executor code only needs to send each row returned by the query plan tree off to the client.INSERT ... SELECT,UPDATE,DELETE, andMERGE are effectivelySELECTs under a special top-level plan node calledModifyTable.
INSERT ... SELECT feeds the rows up toModifyTable for insertion. ForUPDATE, the planner arranges that each computed row includes all the updated column values, plus theTID (tuple ID, or row ID) of the original target row; this data is fed up to theModifyTable node, which uses the information to create a new updated row and mark the old row deleted. ForDELETE, the only column that is actually returned by the plan is the TID, and theModifyTable node simply uses the TID to visit each target row and mark it deleted. ForMERGE, the planner joins the source and target relations, and includes all column values required by any of theWHEN clauses, plus the TID of the target row; this data is fed up to theModifyTable node, which uses the information to work out whichWHEN clause to execute, and then inserts, updates or deletes the target row, as required.
A simpleINSERT ... VALUES command creates a trivial plan tree consisting of a singleResult node, which computes just one result row, feeding that up toModifyTable to perform the insertion.