]> begriffs open source - ai-pg/blob - full-docs/txt/executor.txt
Convert HTML docs to more streamlined TXT
[ai-pg] / full-docs / txt / executor.txt
1
2 51.6. Executor #
3
4    The executor takes the plan created by the planner/optimizer and
5    recursively processes it to extract the required set of rows. This is
6    essentially a demand-pull pipeline mechanism. Each time a plan node is
7    called, it must deliver one more row, or report that it is done
8    delivering rows.
9
10    To provide a concrete example, assume that the top node is a MergeJoin
11    node. Before any merge can be done two rows have to be fetched (one
12    from each subplan). So the executor recursively calls itself to process
13    the subplans (it starts with the subplan attached to lefttree). The new
14    top node (the top node of the left subplan) is, let's say, a Sort node
15    and again recursion is needed to obtain an input row. The child node of
16    the Sort might be a SeqScan node, representing actual reading of a
17    table. Execution of this node causes the executor to fetch a row from
18    the table and return it up to the calling node. The Sort node will
19    repeatedly call its child to obtain all the rows to be sorted. When the
20    input is exhausted (as indicated by the child node returning a NULL
21    instead of a row), the Sort code performs the sort, and finally is able
22    to return its first output row, namely the first one in sorted order.
23    It keeps the remaining rows stored so that it can deliver them in
24    sorted order in response to later demands.
25
26    The MergeJoin node similarly demands the first row from its right
27    subplan. Then it compares the two rows to see if they can be joined; if
28    so, it returns a join row to its caller. On the next call, or
29    immediately if it cannot join the current pair of inputs, it advances
30    to the next row of one table or the other (depending on how the
31    comparison came out), and again checks for a match. Eventually, one
32    subplan or the other is exhausted, and the MergeJoin node returns NULL
33    to indicate that no more join rows can be formed.
34
35    Complex queries can involve many levels of plan nodes, but the general
36    approach is the same: each node computes and returns its next output
37    row each time it is called. Each node is also responsible for applying
38    any selection or projection expressions that were assigned to it by the
39    planner.
40
41    The executor mechanism is used to evaluate all five basic SQL query
42    types: SELECT, INSERT, UPDATE, DELETE, and MERGE. For SELECT, the
43    top-level executor code only needs to send each row returned by the
44    query plan tree off to the client. INSERT ... SELECT, UPDATE, DELETE,
45    and MERGE are effectively SELECTs under a special top-level plan node
46    called ModifyTable.
47
48    INSERT ... SELECT feeds the rows up to ModifyTable for insertion. For
49    UPDATE, the planner arranges that each computed row includes all the
50    updated column values, plus the TID (tuple ID, or row ID) of the
51    original target row; this data is fed up to the ModifyTable node, which
52    uses the information to create a new updated row and mark the old row
53    deleted. For DELETE, the only column that is actually returned by the
54    plan is the TID, and the ModifyTable node simply uses the TID to visit
55    each target row and mark it deleted. For MERGE, the planner joins the
56    source and target relations, and includes all column values required by
57    any of the WHEN clauses, plus the TID of the target row; this data is
58    fed up to the ModifyTable node, which uses the information to work out
59    which WHEN clause to execute, and then inserts, updates or deletes the
60    target row, as required.
61
62    A simple INSERT ... VALUES command creates a trivial plan tree
63    consisting of a single Result node, which computes just one result row,
64    feeding that up to ModifyTable to perform the insertion.