Re: support for MERGE
Zhihong Yu <zyu@yugabyte.com>
From: Zhihong Yu <zyu@yugabyte.com>
To: Andres Freund <andres@anarazel.de>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, Pg Hackers <pgsql-hackers@lists.postgresql.org>, Simon Riggs <simon.riggs@enterprisedb.com>,
Tomas Vondra <tomas.vondra@enterprisedb.com>, Daniel Westermann <dwe@dbi-services.com>,
Amit Langote <amitlangote09@gmail.com>, Justin Pryzby <pryzby@telsasoft.com>, Japin Li <japinli@hotmail.com>,
Erik Rijkers <er@xs4all.nl>, Jaime Casanova <jcasanov@systemguards.com.ec>
Date: 2022-01-28T22:32:37Z
Lists: pgsql-hackers
On Fri, Jan 28, 2022 at 2:19 PM Andres Freund <andres@anarazel.de> wrote: > Hi, > > On 2022-01-28 17:27:37 -0300, Alvaro Herrera wrote: > > MERGE, v10. I am much more comfortable with this version; I have > > removed a bunch of temporary hacks and cleaned up the interactions with > > table AM and executor, which is something that had been bothering me for > > a while. The complete set of changes can be seen in github, > > https://github.com/alvherre/postgres/commits/merge-15 > > Any chance you could split this into something more reviewable? The overall > diff stats are: 102 files changed, 8589 insertions(+), 234 deletions(-) > thats > pretty hard to really review. Incremental commits don't realy help with > that. > > > > I am not aware of anything of significance in terms of remaining work > > for this project. > > One thing from skimming: There's not enough documentation about the > approach > imo - it's a complicated enough feature to deserve more than the one > paragraph > in src/backend/executor/README. > > > I'm still [1],[2] uncomfortable with execMerge.c kinda-but-not-really > being an > executor node. > > > > The one thing I'm a bit bothered about is the fact that we expose a lot > of > > executor functions previously static. I am now wondering if it would be > > better to move the MERGE executor support functions into > nodeModifyTable.c, > > which I think would mean we would not have to expose those function > > prototypes. > > I'm worried about the complexity of nodeModifyTuple.c as is. Moving more > code > Hi, I think you meant nodeModifyTable.c. And I agree with your comment (on not making nodeModifyTable.c bigger). Cheers > in there does not seem like the right call to me - we should do the > opposite > if anything. > > > A few inline comments below. No real review, just stuff noticed while > skimming > to see where this is at. > > > Greetings, > > Andres > > > [1] > https://www.postgresql.org/message-id/20180405200003.gar3j26gsk32gqpe@alap3.anarazel.de > [2] > https://www.postgresql.org/message-id/20180403021800.b5nsgiclzanobiup@alap3.anarazel.de > > >
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