<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>51.6. Executor</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="prev" href="planner-optimizer.html" title="51.5. Planner/Optimizer" /><link rel="next" href="catalogs.html" title="Chapter 52. System Catalogs" /></head><body><div xmlns="http://www.w3.org/TR/xhtml1/transitional" class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">51.6. Executor</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="planner-optimizer.html" title="51.5. Planner/Optimizer">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="overview.html" title="Chapter 51. Overview of PostgreSQL Internals">Up</a></td><th width="60%" align="center">Chapter 51. Overview of PostgreSQL Internals</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 11.5 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="catalogs.html" title="Chapter 52. System Catalogs">Next</a></td></tr></table><hr></hr></div><div class="sect1" id="EXECUTOR"><div class="titlepage"><div><div><h2 class="title" style="clear: both">51.6. Executor</h2></div></div></div><p>
The <em class="firstterm">executor</em> 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.
</p><p>
To provide a concrete example, assume that the top
node is a <code class="literal">MergeJoin</code> 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 to
<code class="literal">lefttree</code>). The new top node (the top node of the left
subplan) is, let's say, a
<code class="literal">Sort</code> node and again recursion is needed to obtain
an input row. The child node of the <code class="literal">Sort</code> might
be a <code class="literal">SeqScan</code> 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. The <code class="literal">Sort</code>
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), the <code class="literal">Sort</code> 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.
</p><p>
The <code class="literal">MergeJoin</code> 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 the <code class="literal">MergeJoin</code> node returns NULL to indicate that
no more join rows can be formed.
</p><p>
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.
</p><p>
The executor mechanism is used to evaluate all four basic SQL query types:
<code class="command">SELECT</code>, <code class="command">INSERT</code>, <code class="command">UPDATE</code>, and
<code class="command">DELETE</code>. For <code class="command">SELECT</code>, the top-level executor
code only needs to send each row returned by the query plan tree off
to the client. For <code class="command">INSERT</code>, each returned row is inserted
into the target table specified for the <code class="command">INSERT</code>. This is
done in a special top-level plan node called <code class="literal">ModifyTable</code>.
(A simple
<code class="command">INSERT ... VALUES</code> command creates a trivial plan tree
consisting of a single <code class="literal">Result</code> node, which computes just one
result row, and <code class="literal">ModifyTable</code> above it to perform the insertion.
But <code class="command">INSERT ... SELECT</code> can demand the full power
of the executor mechanism.) For <code class="command">UPDATE</code>, the planner arranges
that each computed row includes all the updated column values, plus
the <em class="firstterm">TID</em> (tuple ID, or row ID) of the original target row;
this data is fed into a <code class="literal">ModifyTable</code> node, which uses the
information to create a new updated row and mark the old row deleted.
For <code class="command">DELETE</code>, the only column that is actually returned by the
plan is the TID, and the <code class="literal">ModifyTable</code> node simply uses the TID
to visit each target row and mark it deleted.
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="planner-optimizer.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="overview.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="catalogs.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">51.5. Planner/Optimizer </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 52. System Catalogs</td></tr></table></div></body></html>
