Re: support for MERGE
Amit Langote <amitlangote09@gmail.com>
From: Amit Langote <amitlangote09@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Zhihong Yu <zyu@yugabyte.com>, Simon Riggs <simon.riggs@enterprisedb.com>, Pg Hackers <pgsql-hackers@lists.postgresql.org>, Tomas Vondra <tomas.vondra@enterprisedb.com>,
Daniel Westermann <dwe@dbi-services.com>, Justin Pryzby <pryzby@telsasoft.com>, Japin Li <japinli@hotmail.com>,
Erik Rijkers <er@xs4all.nl>, Jaime Casanova <jcasanov@systemguards.com.ec>,
Andres Freund <andres@anarazel.de>
Date: 2022-03-14T14:36:07Z
Lists: pgsql-hackers
On Sun, Mar 13, 2022 at 12:36 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> FYI I intend to get the ModifyTable split patch (0001+0003) pushed
> hopefully on Tuesday or Wednesday next week, unless something really
> ugly is found on it.
I looked at 0001 and found a few things that could perhaps be improved.
+ /* Slot containing tuple obtained from subplan, for RETURNING */
+ TupleTableSlot *planSlot;
I think planSlot is also used by an FDW to look up any FDW-specific
junk attributes that the FDW's scan method would have injected into
the slot, so maybe no need to specifically mention only RETURNING here
as what cares about it.
+ /*
+ * The tuple produced by EvalPlanQual to retry from, if a cross-partition
+ * UPDATE requires it
+ */
+ TupleTableSlot *retrySlot;
Maybe a bit long name, though how about calling this updateRetrySlot
to make it apparent that what is to be retried with the slot is the
whole UPDATE operation, not some sub-operation (like say the
cross-partition portion)?
+ /*
+ * The tuple projected by the INSERT's RETURNING clause, when doing a
+ * cross-partition UPDATE
+ */
+ TupleTableSlot *projectedFromInsert;
I'd have gone with cpUpdateReturningSlot here, because that is what it
looks to me to be. The fact that it is ExecInsert() that computes the
RETURNING targetlist projection seems like an implementation detail.
I know you said you don't like having "Slot" in the name, but then we
also have retrySlot. :)
+/*
+ * Context struct containing output data specific to UPDATE operations.
+ */
+typedef struct UpdateContext
+{
+ bool updateIndexes; /* index update required? */
+ bool crossPartUpdate; /* was it a cross-partition update? */
+} UpdateContext;
I wonder if it isn't more readable to just have these two be the
output arguments of ExecUpdateAct()?
+redo_act:
+ /* XXX reinit ->crossPartUpdate here? */
Why not just make ExecUpdateAct() always set the flag, not only when a
cross-partition update does occur?
Will look some more in the morning tomorrow.
--
Amit Langote
EDB: http://www.enterprisedb.com
Commits
-
Doc fixes for MERGE statement
- 5dcebd10baa8 16.0 landed
- 5bb88967ed5c 15.0 landed
-
MERGE docs adjustments
- d6d1fbf353d1 15.0 landed
- 3d895bc846f2 16.0 landed
-
Link to MVCC docs in MERGE docs
- ffffeebf2447 15.0 landed
-
Fix EXPLAIN MERGE output when no tuples are processed
- 12e423e21d8e 15.0 landed
-
Make EXPLAIN MERGE output format more compact
- 598ac10be1c2 15.0 landed
-
Add support for MERGE SQL command
- 7103ebb7aae8 15.0 landed
-
Split ExecUpdate and ExecDelete into reusable pieces
- 25e777cf8e54 15.0 landed
-
Add API of sorts for transition table handling in trigger.c
- 3a46a45f6f00 15.0 landed
-
Represent Lists as expansible arrays, not chains of cons-cells.
- 1cff1b95ab6d 13.0 cited