rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

doc: expand description of how non-SELECT queries are processed 

The previous description of how the executor processes non-SELECT
queries was very dense, causing lack of clarity.  This expanded text
spells it out more simply.

Reported-by: fotis.koutoupas@gmail.com

Discussion: https://postgr.es/m/160912275508.676.17469511338925622905@wrigleys.postgresql.org

Backpatch-through: 9.5
This commit is contained in:
Bruce Momjian 2021-01-09 12:11:16 -05:00
parent e33d004900
commit 01334c92fa
1 changed files with 30 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

50
doc/src/sgml/arch-dev.sgml
View File

@ -529,26 +529,36 @@
</para> </para>
<para> <para>
The executor mechanism is used to evaluate all four basic SQL query types: The executor mechanism is used to evaluate all four basic SQL query
<command>SELECT</command>, <command>INSERT</command>, <command>UPDATE</command>, and types: <command>SELECT</command>, <command>INSERT</command>,
<command>DELETE</command>. For <command>SELECT</command>, the top-level executor <command>UPDATE</command>, and <command>DELETE</command>.
code only needs to send each row returned by the query plan tree off For <command>SELECT</command>, the top-level executor code
to the client. For <command>INSERT</command>, each returned row is inserted only needs to send each row returned by the query plan tree
into the target table specified for the <command>INSERT</command>. This is off to the client. <command>INSERT ... SELECT</command>,
done in a special top-level plan node called <literal>ModifyTable</literal>. <command>UPDATE</command>, and <command>DELETE</command>
(A simple are effectively <command>SELECT</command>s under a special
<command>INSERT ... VALUES</command> command creates a trivial plan tree top-level plan node called <literal>ModifyTable</literal>.
consisting of a single <literal>Result</literal> node, which computes just one </para>
result row, and <literal>ModifyTable</literal> above it to perform the insertion.
But <command>INSERT ... SELECT</command> can demand the full power <para>
of the executor mechanism.) For <command>UPDATE</command>, the planner arranges <command>INSERT ... SELECT</command> feeds the rows up
that each computed row includes all the updated column values, plus to <literal>ModifyTable</literal> for insertion. For
the <firstterm>TID</firstterm> (tuple ID, or row ID) of the original target row; <command>UPDATE</command>, the planner arranges that each
this data is fed into a <literal>ModifyTable</literal> node, which uses the computed row includes all the updated column values, plus the
information to create a new updated row and mark the old row deleted. <firstterm>TID</firstterm> (tuple ID, or row ID) of the original
For <command>DELETE</command>, the only column that is actually returned by the target row; this data is fed up to the <literal>ModifyTable</literal>
plan is the TID, and the <literal>ModifyTable</literal> node simply uses the TID node, which uses the information to create a new updated row and
to visit each target row and mark it deleted. mark the old row deleted. For <command>DELETE</command>, the only
column that is actually returned by the plan is the TID, and the
<literal>ModifyTable</literal> node simply uses the TID to visit each
target row and mark it deleted.
</para>
<para>
A simple <command>INSERT ... VALUES</command> command creates a
trivial plan tree consisting of a single <literal>Result</literal>
node, which computes just one result row, feeding that up
to<literal>ModifyTable</literal> to perform the insertion.
</para> </para>
</sect1> </sect1>