Skip to content

Commit 8a5849b

Browse files
tglsfdctglsfdc
committed
Split the processing of INSERT/UPDATE/DELETE operations out of execMain.c.
They are now handled by a new plan node type called ModifyTable, which is placed at the top of the plan tree. In itself this change doesn't do much, except perhaps make the handling of RETURNING lists and inherited UPDATEs a tad less klugy. But it is necessary preparation for the intended extension of allowing RETURNING queries inside WITH. Marko Tiikkaja
1 parent b865d27 commit 8a5849b

30 files changed

+1545
-1100
lines changed

‎doc/src/sgml/arch-dev.sgml

Lines changed: 28 additions & 24 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/arch-dev.sgml,v 2.32 2009/04/27 16:27:35 momjian Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/arch-dev.sgml,v 2.33 2009/10/10 01:43:45 tgl Exp $ -->
22

33
<chapter id="overview">
44
<title>Overview of PostgreSQL Internals</title>
@@ -58,7 +58,7 @@
5858
The <firstterm>rewrite system</firstterm> takes
5959
the query tree created by the parser stage and looks for
6060
any <firstterm>rules</firstterm> (stored in the
61-
<firstterm>system catalogs</firstterm>) to apply to
61+
<firstterm>system catalogs</firstterm>) to apply to
6262
the query tree. It performs the
6363
transformations given in the <firstterm>rule bodies</firstterm>.
6464
</para>
@@ -77,7 +77,7 @@
7777
<step>
7878
<para>
7979
The <firstterm>planner/optimizer</firstterm> takes
80-
the (rewritten) query tree and creates a
80+
the (rewritten) query tree and creates a
8181
<firstterm>query plan</firstterm> that will be the input to the
8282
<firstterm>executor</firstterm>.
8383
</para>
@@ -163,8 +163,8 @@
163163
<para>
164164
The <firstterm>parser</firstterm> defined in
165165
<filename>gram.y</filename> and <filename>scan.l</filename> is
166-
built using the Unix tools <application>yacc</application>
167-
and <application>lex</application>.
166+
built using the Unix tools <application>bison</application>
167+
and <application>flex</application>.
168168
</para>
169169
</listitem>
170170
<listitem>
@@ -184,8 +184,8 @@
184184
ASCII text) for valid syntax. If the syntax is correct a
185185
<firstterm>parse tree</firstterm> is built up and handed back;
186186
otherwise an error is returned. The parser and lexer are
187-
implemented using the well-known Unix tools <application>yacc</>
188-
and <application>lex</>.
187+
implemented using the well-known Unix tools <application>bison</>
188+
and <application>flex</>.
189189
</para>
190190

191191
<para>
@@ -208,13 +208,13 @@
208208
<para>
209209
The file <filename>scan.l</filename> is transformed to the C
210210
source file <filename>scan.c</filename> using the program
211-
<application>lex</application> and <filename>gram.y</filename> is
211+
<application>flex</application> and <filename>gram.y</filename> is
212212
transformed to <filename>gram.c</filename> using
213-
<application>yacc</application>. After these transformations
213+
<application>bison</application>. After these transformations
214214
have taken place a normal C compiler can be used to create the
215215
parser. Never make any changes to the generated C files as they
216-
will be overwritten the next time <application>lex</application>
217-
or <application>yacc</application> is called.
216+
will be overwritten the next time <application>flex</application>
217+
or <application>bison</application> is called.
218218

219219
<note>
220220
<para>
@@ -227,12 +227,12 @@
227227
</para>
228228

229229
<para>
230-
A detailed description of <application>yacc</application> or
230+
A detailed description of <application>bison</application> or
231231
the grammar rules given in <filename>gram.y</filename> would be
232232
beyond the scope of this paper. There are many books and
233-
documents dealing with <application>lex</application> and
234-
<application>yacc</application>. You should be familiar with
235-
<application>yacc</application> before you start to study the
233+
documents dealing with <application>flex</application> and
234+
<application>bison</application>. You should be familiar with
235+
<application>bison</application> before you start to study the
236236
grammar given in <filename>gram.y</filename> otherwise you won't
237237
understand what happens there.
238238
</para>
@@ -299,7 +299,7 @@
299299
called whenever an individual row had been accessed. This
300300
implementation was removed in 1995 when the last official release
301301
of the <productname>Berkeley Postgres</productname> project was
302-
transformed into <productname>Postgres95</productname>.
302+
transformed into <productname>Postgres95</productname>.
303303
</para>
304304
</listitem>
305305

@@ -479,7 +479,7 @@
479479
<title>Executor</title>
480480

481481
<para>
482-
The <firstterm>executor</firstterm> takes the plan handed back by the
482+
The <firstterm>executor</firstterm> takes the plan created by the
483483
planner/optimizer and recursively processes it to extract the required set
484484
of rows. This is essentially a demand-pull pipeline mechanism.
485485
Each time a plan node is called, it must deliver one more row, or
@@ -488,7 +488,7 @@
488488

489489
<para>
490490
To provide a concrete example, assume that the top
491-
node is a <literal>MergeJoin</literal> node.
491+
node is a <literal>MergeJoin</literal> node.
492492
Before any merge can be done two rows have to be fetched (one from
493493
each subplan). So the executor recursively calls itself to
494494
process the subplans (it starts with the subplan attached to
@@ -533,17 +533,21 @@
533533
<command>DELETE</>. For <command>SELECT</>, the top-level executor
534534
code only needs to send each row returned by the query plan tree off
535535
to the client. For <command>INSERT</>, each returned row is inserted
536-
into the target table specified for the <command>INSERT</>. (A simple
536+
into the target table specified for the <command>INSERT</>. This is
537+
done in a special top-level plan node called <literal>ModifyTable</>.
538+
(A simple
537539
<command>INSERT ... VALUES</> command creates a trivial plan tree
538540
consisting of a single <literal>Result</> node, which computes just one
539-
result row. But <command>INSERT ... SELECT</> can demand the full power
541+
result row, and <literal>ModifyTable</> above it to perform the insertion.
542+
But <command>INSERT ... SELECT</> can demand the full power
540543
of the executor mechanism.) For <command>UPDATE</>, the planner arranges
541544
that each computed row includes all the updated column values, plus
542545
the <firstterm>TID</> (tuple ID, or row ID) of the original target row;
543-
the executor top level uses this information to create a new updated row
544-
and mark the old row deleted. For <command>DELETE</>, the only column
545-
that is actually returned by the plan is the TID, and the executor top
546-
level simply uses the TID to visit each target row and mark it deleted.
546+
this data is fed into a <literal>ModifyTable</> node, which uses the
547+
information to create a new updated row and mark the old row deleted.
548+
For <command>DELETE</>, the only column that is actually returned by the
549+
plan is the TID, and the <literal>ModifyTable</> node simply uses the TID
550+
to visit each target row and mark it deleted.
547551
</para>
548552

549553
</sect1>

‎src/backend/commands/explain.c

Lines changed: 30 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@
77
* Portions Copyright (c) 1994-5, Regents of the University of California
88
*
99
* IDENTIFICATION
10-
* $PostgreSQL: pgsql/src/backend/commands/explain.c,v 1.190 2009/08/22 02:06:32 tgl Exp $
10+
* $PostgreSQL: pgsql/src/backend/commands/explain.c,v 1.191 2009/10/10 01:43:45 tgl Exp $
1111
*
1212
*-------------------------------------------------------------------------
1313
*/
@@ -581,6 +581,7 @@ ExplainNode(Plan *plan, PlanState *planstate,
581581
const char *pname; /* node type name for text output */
582582
const char *sname; /* node type name for non-text output */
583583
const char *strategy = NULL;
584+
const char *operation = NULL;
584585
int save_indent = es->indent;
585586
bool haschildren;
586587

@@ -591,6 +592,24 @@ ExplainNode(Plan *plan, PlanState *planstate,
591592
case T_Result:
592593
pname = sname = "Result";
593594
break;
595+
case T_ModifyTable:
596+
sname = "ModifyTable";
597+
switch (((ModifyTable *) plan)->operation)
598+
{
599+
case CMD_INSERT:
600+
pname = operation = "Insert";
601+
break;
602+
case CMD_UPDATE:
603+
pname = operation = "Update";
604+
break;
605+
case CMD_DELETE:
606+
pname = operation = "Delete";
607+
break;
608+
default:
609+
pname = "???";
610+
break;
611+
}
612+
break;
594613
case T_Append:
595614
pname = sname = "Append";
596615
break;
@@ -736,6 +755,8 @@ ExplainNode(Plan *plan, PlanState *planstate,
736755
ExplainPropertyText("Node Type", sname, es);
737756
if (strategy)
738757
ExplainPropertyText("Strategy", strategy, es);
758+
if (operation)
759+
ExplainPropertyText("Operation", operation, es);
739760
if (relationship)
740761
ExplainPropertyText("Parent Relationship", relationship, es);
741762
if (plan_name)
@@ -1023,6 +1044,7 @@ ExplainNode(Plan *plan, PlanState *planstate,
10231044
haschildren = plan->initPlan ||
10241045
outerPlan(plan) ||
10251046
innerPlan(plan) ||
1047+
IsA(plan, ModifyTable) ||
10261048
IsA(plan, Append) ||
10271049
IsA(plan, BitmapAnd) ||
10281050
IsA(plan, BitmapOr) ||
@@ -1059,6 +1081,11 @@ ExplainNode(Plan *plan, PlanState *planstate,
10591081
/* special child plans */
10601082
switch (nodeTag(plan))
10611083
{
1084+
case T_ModifyTable:
1085+
ExplainMemberNodes(((ModifyTable *) plan)->plans,
1086+
((ModifyTableState *) planstate)->mt_plans,
1087+
outer_plan, es);
1088+
break;
10621089
case T_Append:
10631090
ExplainMemberNodes(((Append *) plan)->appendplans,
10641091
((AppendState *) planstate)->appendplans,
@@ -1408,7 +1435,8 @@ ExplainScanTarget(Scan *plan, ExplainState *es)
14081435
}
14091436

14101437
/*
1411-
* Explain the constituent plans of an Append, BitmapAnd, or BitmapOr node.
1438+
* Explain the constituent plans of a ModifyTable, Append, BitmapAnd,
1439+
* or BitmapOr node.
14121440
*
14131441
* Ordinarily we don't pass down outer_plan to our child nodes, but in these
14141442
* cases we must, since the node could be an "inner indexscan" in which case

‎src/backend/commands/trigger.c

Lines changed: 22 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@
77
* Portions Copyright (c) 1994, Regents of the University of California
88
*
99
* IDENTIFICATION
10-
* $PostgreSQL: pgsql/src/backend/commands/trigger.c,v 1.252 2009/08/04 16:08:36 tgl Exp $
10+
* $PostgreSQL: pgsql/src/backend/commands/trigger.c,v 1.253 2009/10/10 01:43:45 tgl Exp $
1111
*
1212
*-------------------------------------------------------------------------
1313
*/
@@ -55,6 +55,7 @@ int SessionReplicationRole = SESSION_REPLICATION_ROLE_ORIGIN;
5555
static void ConvertTriggerToFK(CreateTrigStmt *stmt, Oid funcoid);
5656
static void InsertTrigger(TriggerDesc *trigdesc, Trigger *trigger, int indx);
5757
static HeapTuple GetTupleForTrigger(EState *estate,
58+
PlanState *subplanstate,
5859
ResultRelInfo *relinfo,
5960
ItemPointer tid,
6061
TupleTableSlot **newSlot);
@@ -1793,7 +1794,8 @@ ExecASDeleteTriggers(EState *estate, ResultRelInfo *relinfo)
17931794
}
17941795

17951796
bool
1796-
ExecBRDeleteTriggers(EState *estate, ResultRelInfo *relinfo,
1797+
ExecBRDeleteTriggers(EState *estate, PlanState *subplanstate,
1798+
ResultRelInfo *relinfo,
17971799
ItemPointer tupleid)
17981800
{
17991801
TriggerDesc *trigdesc = relinfo->ri_TrigDesc;
@@ -1806,7 +1808,8 @@ ExecBRDeleteTriggers(EState *estate, ResultRelInfo *relinfo,
18061808
TupleTableSlot *newSlot;
18071809
int i;
18081810

1809-
trigtuple = GetTupleForTrigger(estate, relinfo, tupleid, &newSlot);
1811+
trigtuple = GetTupleForTrigger(estate, subplanstate, relinfo, tupleid,
1812+
&newSlot);
18101813
if (trigtuple == NULL)
18111814
return false;
18121815

@@ -1862,7 +1865,7 @@ ExecARDeleteTriggers(EState *estate, ResultRelInfo *relinfo,
18621865

18631866
if (trigdesc && trigdesc->n_after_row[TRIGGER_EVENT_DELETE] > 0)
18641867
{
1865-
HeapTuple trigtuple = GetTupleForTrigger(estate, relinfo,
1868+
HeapTuple trigtuple = GetTupleForTrigger(estate, NULL, relinfo,
18661869
tupleid, NULL);
18671870

18681871
AfterTriggerSaveEvent(relinfo, TRIGGER_EVENT_DELETE,
@@ -1941,7 +1944,8 @@ ExecASUpdateTriggers(EState *estate, ResultRelInfo *relinfo)
19411944
}
19421945

19431946
HeapTuple
1944-
ExecBRUpdateTriggers(EState *estate, ResultRelInfo *relinfo,
1947+
ExecBRUpdateTriggers(EState *estate, PlanState *subplanstate,
1948+
ResultRelInfo *relinfo,
19451949
ItemPointer tupleid, HeapTuple newtuple)
19461950
{
19471951
TriggerDesc *trigdesc = relinfo->ri_TrigDesc;
@@ -1954,16 +1958,18 @@ ExecBRUpdateTriggers(EState *estate, ResultRelInfo *relinfo,
19541958
TupleTableSlot *newSlot;
19551959
int i;
19561960

1957-
trigtuple = GetTupleForTrigger(estate, relinfo, tupleid, &newSlot);
1961+
trigtuple = GetTupleForTrigger(estate, subplanstate, relinfo, tupleid,
1962+
&newSlot);
19581963
if (trigtuple == NULL)
19591964
return NULL;
19601965

19611966
/*
19621967
* In READ COMMITTED isolation level it's possible that newtuple was
1963-
* changed due to concurrent update.
1968+
* changed due to concurrent update. In that case we have a raw subplan
1969+
* output tuple and need to run it through the junk filter.
19641970
*/
19651971
if (newSlot != NULL)
1966-
intuple = newtuple = ExecRemoveJunk(estate->es_junkFilter, newSlot);
1972+
intuple = newtuple = ExecRemoveJunk(relinfo->ri_junkFilter, newSlot);
19671973

19681974
LocTriggerData.type = T_TriggerData;
19691975
LocTriggerData.tg_event = TRIGGER_EVENT_UPDATE |
@@ -2014,7 +2020,7 @@ ExecARUpdateTriggers(EState *estate, ResultRelInfo *relinfo,
20142020

20152021
if (trigdesc && trigdesc->n_after_row[TRIGGER_EVENT_UPDATE] > 0)
20162022
{
2017-
HeapTuple trigtuple = GetTupleForTrigger(estate, relinfo,
2023+
HeapTuple trigtuple = GetTupleForTrigger(estate, NULL, relinfo,
20182024
tupleid, NULL);
20192025

20202026
AfterTriggerSaveEvent(relinfo, TRIGGER_EVENT_UPDATE,
@@ -2094,7 +2100,9 @@ ExecASTruncateTriggers(EState *estate, ResultRelInfo *relinfo)
20942100

20952101

20962102
static HeapTuple
2097-
GetTupleForTrigger(EState *estate, ResultRelInfo *relinfo,
2103+
GetTupleForTrigger(EState *estate,
2104+
PlanState *subplanstate,
2105+
ResultRelInfo *relinfo,
20982106
ItemPointer tid,
20992107
TupleTableSlot **newSlot)
21002108
{
@@ -2111,6 +2119,9 @@ GetTupleForTrigger(EState *estate, ResultRelInfo *relinfo,
21112119

21122120
*newSlot = NULL;
21132121

2122+
/* caller must pass a subplanstate if EvalPlanQual is possible */
2123+
Assert(subplanstate != NULL);
2124+
21142125
/*
21152126
* lock tuple for update
21162127
*/
@@ -2143,6 +2154,7 @@ ltrmark:;
21432154

21442155
epqslot = EvalPlanQual(estate,
21452156
relinfo->ri_RangeTableIndex,
2157+
subplanstate,
21462158
&update_ctid,
21472159
update_xmax);
21482160
if (!TupIsNull(epqslot))

‎src/backend/executor/Makefile

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,7 @@
44
# Makefile for executor
55
#
66
# IDENTIFICATION
7-
# $PostgreSQL: pgsql/src/backend/executor/Makefile,v 1.29 2008/12/28 18:53:55 tgl Exp $
7+
# $PostgreSQL: pgsql/src/backend/executor/Makefile,v 1.30 2009/10/10 01:43:45 tgl Exp $
88
#
99
#-------------------------------------------------------------------------
1010

@@ -18,6 +18,7 @@ OBJS = execAmi.o execCurrent.o execGrouping.o execJunk.o execMain.o \
1818
nodeBitmapAnd.o nodeBitmapOr.o \
1919
nodeBitmapHeapscan.o nodeBitmapIndexscan.o nodeHash.o \
2020
nodeHashjoin.o nodeIndexscan.o nodeMaterial.o nodeMergejoin.o \
21+
nodeModifyTable.o \
2122
nodeNestloop.o nodeFunctionscan.o nodeRecursiveunion.o nodeResult.o \
2223
nodeSeqscan.o nodeSetOp.o nodeSort.o nodeUnique.o \
2324
nodeValuesscan.o nodeCtescan.o nodeWorktablescan.o \

‎src/backend/executor/README

Lines changed: 12 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
$PostgreSQL: pgsql/src/backend/executor/README,v 1.8 2009/01/09 15:46:10 tgl Exp $
1+
$PostgreSQL: pgsql/src/backend/executor/README,v 1.9 2009/10/10 01:43:45 tgl Exp $
22

33
The Postgres Executor
44
=====================
@@ -25,16 +25,17 @@ There is a moderately intelligent scheme to avoid rescanning nodes
2525
unnecessarily (for example, Sort does not rescan its input if no parameters
2626
of the input have changed, since it can just reread its stored sorted data).
2727

28-
The plan tree concept implements SELECT directly: it is only necessary to
29-
deliver the top-level result tuples to the client, or insert them into
30-
another table in the case of INSERT ... SELECT. (INSERT ... VALUES is
31-
handled similarly, but the plan tree is just a Result node with no source
32-
tables.) For UPDATE, the plan tree selects the tuples that need to be
33-
updated (WHERE condition) and delivers a new calculated tuple value for each
34-
such tuple, plus a "junk" (hidden) tuple CTID identifying the target tuple.
35-
The executor's top level then uses this information to update the correct
36-
tuple. DELETE is similar to UPDATE except that only a CTID need be
37-
delivered by the plan tree.
28+
For a SELECT, it is only necessary to deliver the top-level result tuples
29+
to the client. For INSERT/UPDATE/DELETE, the actual table modification
30+
operations happen in a top-level ModifyTable plan node. If the query
31+
includes a RETURNING clause, the ModifyTable node delivers the computed
32+
RETURNING rows as output, otherwise it returns nothing. Handling INSERT
33+
is pretty straightforward: the tuples returned from the plan tree below
34+
ModifyTable are inserted into the correct result relation. For UPDATE,
35+
the plan tree returns the computed tuples to be updated, plus a "junk"
36+
(hidden) CTID column identifying which table row is to be replaced by each
37+
one. For DELETE, the plan tree need only deliver a CTID column, and the
38+
ModifyTable node visits each of those rows and marks the row deleted.
3839

3940
XXX a great deal more documentation needs to be written here...
4041

0 commit comments

Comments
 (0)