diff options
| author | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-16 19:46:48 +0000 |
|---|---|---|
| committer | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-16 19:46:48 +0000 |
| commit | 311bcfc6b3acdd6fd152798c7f287ddf74fa2a98 (patch) | |
| tree | 0ec307299b1dada3701e42f4ca6eda57d708261e /doc/src/sgml/html/executor.html | |
| parent | Initial commit. (diff) | |
| download | postgresql-15-311bcfc6b3acdd6fd152798c7f287ddf74fa2a98.tar.xz postgresql-15-311bcfc6b3acdd6fd152798c7f287ddf74fa2a98.zip | |
Adding upstream version 15.4.upstream/15.4upstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'doc/src/sgml/html/executor.html')
| -rw-r--r-- | doc/src/sgml/html/executor.html | 78 |
1 files changed, 78 insertions, 0 deletions
diff --git a/doc/src/sgml/html/executor.html b/doc/src/sgml/html/executor.html new file mode 100644 index 0000000..bd8ea65 --- /dev/null +++ b/doc/src/sgml/html/executor.html @@ -0,0 +1,78 @@ +<?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>52.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="52.5. Planner/Optimizer" /><link rel="next" href="catalogs.html" title="Chapter 53. 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">52.6. Executor</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="planner-optimizer.html" title="52.5. Planner/Optimizer">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="overview.html" title="Chapter 52. Overview of PostgreSQL Internals">Up</a></td><th width="60%" align="center">Chapter 52. Overview of PostgreSQL Internals</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 15.4 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="catalogs.html" title="Chapter 53. 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">52.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 five basic SQL query + types: <code class="command">SELECT</code>, <code class="command">INSERT</code>, + <code class="command">UPDATE</code>, <code class="command">DELETE</code>, and + <code class="command">MERGE</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. <code class="command">INSERT ... SELECT</code>, + <code class="command">UPDATE</code>, <code class="command">DELETE</code>, and + <code class="command">MERGE</code> + are effectively <code class="command">SELECT</code>s under a special + top-level plan node called <code class="literal">ModifyTable</code>. + </p><p> + <code class="command">INSERT ... SELECT</code> feeds the rows up + to <code class="literal">ModifyTable</code> for insertion. 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 up to the <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. For <code class="command">MERGE</code>, the + planner joins the source and target relations, and includes all + column values required by any of the <code class="literal">WHEN</code> clauses, + plus the TID of the target row; this data is fed up to the + <code class="literal">ModifyTable</code> node, which uses the information to + work out which <code class="literal">WHEN</code> clause to execute, and then + inserts, updates or deletes the target row, as required. + </p><p> + 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, feeding that up + to <code class="literal">ModifyTable</code> to perform the insertion. + </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="52.5. Planner/Optimizer">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="overview.html" title="Chapter 52. Overview of PostgreSQL Internals">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="catalogs.html" title="Chapter 53. System Catalogs">Next</a></td></tr><tr><td width="40%" align="left" valign="top">52.5. Planner/Optimizer </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 15.4 Documentation">Home</a></td><td width="40%" align="right" valign="top"> Chapter 53. System Catalogs</td></tr></table></div></body></html>
\ No newline at end of file |