mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-23 13:50:40 +02:00
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:
parent
769908811b
commit
21c9decc6b
@ -528,26 +528,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>
|
||||||
|
Loading…
Reference in New Issue
Block a user