User-Agent: Cyrus-JMAP/3.5.0-alpha0-4778-g14fba9972e-fm-20220217.001-g14fba997
Mime-Version: 1.0
Message-Id: <2fcf717a-c542-466a-9031-d2c18206e5c2@www.fastmail.com>
In-Reply-To: <7d41dcb8-ca24-40e1-b361-e7ec889e9124@www.fastmail.com>
References: <202202271735.4o6uyat2eh7w@alvherre.pgsql>
 <7d41dcb8-ca24-40e1-b361-e7ec889e9124@www.fastmail.com>
Date: Mon, 07 Mar 2022 17:04:01 -0300
From: =?UTF-8?Q?=C3=81lvaro_Herrera?= <alvherre@alvh.no-ip.org>
To: "Andres Freund" <andres@anarazel.de>
Cc: 
 "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>,
 "Simon Riggs" <simon.riggs@enterprisedb.com>,
 "Tomas Vondra" <tomas.vondra@enterprisedb.com>,
 "Zhihong Yu" <zyu@yugabyte.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>
Subject: Re: support for MERGE
Content-Type: multipart/alternative;
 boundary=cfbedb626aac4374a2c2b8ef594fd7b1
Archived-At: <https://www.postgresql.org/message-id/2fcf717a-c542-466a-9031-d2c18206e5c2%40www.fastmail.com>
Precedence: bulk

--cfbedb626aac4374a2c2b8ef594fd7b1
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 7, 2022, at 4:59 PM, =C3=81lvaro Herrera wrote:
> I attach v13 here.  This version includes a 0002 that's does the split=
 of nodeModifyTable.c routines, then 0003 implements MERGE on top of tha=
t.  0001 is as before.

In 0002, I've opted to have two separate structs.  One is the ModifyTabl=
eContext, as before, but I've removed 'tupleid' and 'oldtuple' (the spec=
ification of the tuple to delete/update) because it makes ExecCrossParti=
tionUpdate cleaner if we pass them separately.  The second struct is Upd=
ateContext, which is used inside ExecUpdate as output data from its subr=
outines.  This is also for the benefit of cross-partition updates.

I'm pretty happy with how this turned out; even without considering MERG=
E, it seems to me that ExecUpdate benefits from being shorter.
--cfbedb626aac4374a2c2b8ef594fd7b1
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">
p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Mon, Ma=
r 7, 2022, at 4:59 PM, =C3=81lvaro Herrera wrote:<br></div><blockquote t=
ype=3D"cite" id=3D"qt" style=3D""><div>I attach v13 here.&nbsp; This ver=
sion includes a 0002 that's does the split of nodeModifyTable.c routines=
, then 0003 implements MERGE on top of that.&nbsp; 0001 is as before.<br=
></div></blockquote><div><br></div><div>In 0002, I've opted to have two =
separate structs.&nbsp; One is the ModifyTableContext, as before, but I'=
ve removed 'tupleid' and 'oldtuple' (the specification of the tuple to d=
elete/update) because it makes ExecCrossPartitionUpdate cleaner if we pa=
ss them separately.&nbsp; The second struct is UpdateContext, which is u=
sed inside ExecUpdate as output data from its subroutines.&nbsp; This is=
 also for the benefit of cross-partition updates.<br></div><div><br></di=
v><div>I'm pretty happy with how this turned out; even without consideri=
ng MERGE, it seems to me that ExecUpdate benefits from being shorter.</d=
iv></body></html>
--cfbedb626aac4374a2c2b8ef594fd7b1--