begriffs open source - ai-pg/blob - full-docs/html/executor.html

   1 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
   2 <!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 id="docContent" class="container-fluid col-10"><div 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 18.0 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 /></div><div class="sect1" id="EXECUTOR"><div class="titlepage"><div><div><h2 class="title" style="clear: both">51.6. Executor <a href="#EXECUTOR" class="id_link">#</a></h2></div></div></div><p>
   3     The <em class="firstterm">executor</em> takes the plan created by the
   4     planner/optimizer and recursively processes it to extract the required set
   5     of rows.  This is essentially a demand-pull pipeline mechanism.
   6     Each time a plan node is called, it must deliver one more row, or
   7     report that it is done delivering rows.
   8    </p><p>
   9     To provide a concrete example, assume that the top
  10     node is a <code class="literal">MergeJoin</code> node.
  11     Before any merge can be done two rows have to be fetched (one from
  12     each subplan). So the executor recursively calls itself to
  13     process the subplans (it starts with the subplan attached to
  14     <code class="literal">lefttree</code>). The new top node (the top node of the left
  15     subplan) is, let's say, a
  16     <code class="literal">Sort</code> node and again recursion is needed to obtain
  17     an input row.  The child node of the <code class="literal">Sort</code> might
  18     be a <code class="literal">SeqScan</code> node, representing actual reading of a table.
  19     Execution of this node causes the executor to fetch a row from the
  20     table and return it up to the calling node.  The <code class="literal">Sort</code>
  21     node will repeatedly call its child to obtain all the rows to be sorted.
  22     When the input is exhausted (as indicated by the child node returning
  23     a NULL instead of a row), the <code class="literal">Sort</code> code performs
  24     the sort, and finally is able to return its first output row, namely
  25     the first one in sorted order.  It keeps the remaining rows stored so
  26     that it can deliver them in sorted order in response to later demands.
  27    </p><p>
  28     The <code class="literal">MergeJoin</code> node similarly demands the first row
  29     from its right subplan.  Then it compares the two rows to see if they
  30     can be joined; if so, it returns a join row to its caller.  On the next
  31     call, or immediately if it cannot join the current pair of inputs,
  32     it advances to the next row of one table
  33     or the other (depending on how the comparison came out), and again
  34     checks for a match.  Eventually, one subplan or the other is exhausted,
  35     and the <code class="literal">MergeJoin</code> node returns NULL to indicate that
  36     no more join rows can be formed.
  37    </p><p>
  38     Complex queries can involve many levels of plan nodes, but the general
  39     approach is the same: each node computes and returns its next output
  40     row each time it is called.  Each node is also responsible for applying
  41     any selection or projection expressions that were assigned to it by
  42     the planner.
  43    </p><p>
  44     The executor mechanism is used to evaluate all five basic SQL query
  45     types: <code class="command">SELECT</code>, <code class="command">INSERT</code>,
  46     <code class="command">UPDATE</code>, <code class="command">DELETE</code>, and
  47     <code class="command">MERGE</code>.
  48     For <code class="command">SELECT</code>, the top-level executor code
  49     only needs to send each row returned by the query plan tree
  50     off to the client.  <code class="command">INSERT ... SELECT</code>,
  51     <code class="command">UPDATE</code>, <code class="command">DELETE</code>, and
  52     <code class="command">MERGE</code>
  53     are effectively <code class="command">SELECT</code>s under a special
  54     top-level plan node called <code class="literal">ModifyTable</code>.
  55    </p><p>
  56     <code class="command">INSERT ... SELECT</code> feeds the rows up
  57     to <code class="literal">ModifyTable</code> for insertion.  For
  58     <code class="command">UPDATE</code>, the planner arranges that each
  59     computed row includes all the updated column values, plus the
  60     <em class="firstterm">TID</em> (tuple ID, or row ID) of the original
  61     target row; this data is fed up to the <code class="literal">ModifyTable</code>
  62     node, which uses the information to create a new updated row and
  63     mark the old row deleted.  For <code class="command">DELETE</code>, the only
  64     column that is actually returned by the plan is the TID, and the
  65     <code class="literal">ModifyTable</code> node simply uses the TID to visit each
  66     target row and mark it deleted.  For <code class="command">MERGE</code>, the
  67     planner joins the source and target relations, and includes all
  68     column values required by any of the <code class="literal">WHEN</code> clauses,
  69     plus the TID of the target row; this data is fed up to the
  70     <code class="literal">ModifyTable</code> node, which uses the information to
  71     work out which <code class="literal">WHEN</code> clause to execute, and then
  72     inserts, updates or deletes the target row, as required.
  73    </p><p>
  74     A simple <code class="command">INSERT ... VALUES</code> command creates a
  75     trivial plan tree consisting of a single <code class="literal">Result</code>
  76     node, which computes just one result row, feeding that up
  77     to <code class="literal">ModifyTable</code> to perform the insertion.
  78    </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" title="51.5. Planner/Optimizer">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="overview.html" title="Chapter 51. Overview of PostgreSQL Internals">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="catalogs.html" title="Chapter 52. System Catalogs">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" title="PostgreSQL 18.0 Documentation">Home</a></td><td width="40%" align="right" valign="top"> Chapter 52. System Catalogs</td></tr></table></div></body></html>