Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1muDCL-0005b3-Sa for pgsql-hackers@arkaria.postgresql.org; Mon, 06 Dec 2021 12:34:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1muDCK-0007BD-I5 for pgsql-hackers@arkaria.postgresql.org; Mon, 06 Dec 2021 12:34:24 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1muDCI-0007Aj-T4 for pgsql-hackers@lists.postgresql.org; Mon, 06 Dec 2021 12:34:24 +0000 Received: from new3-smtp.messagingengine.com ([66.111.4.229]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1muDCE-0000tQ-5z for pgsql-hackers@lists.postgresql.org; Mon, 06 Dec 2021 12:34:22 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailnew.nyi.internal (Postfix) with ESMTP id 60A93580700; Mon, 6 Dec 2021 07:34:15 -0500 (EST) Received: from imap49 ([10.202.2.99]) by compute5.internal (MEProxy); Mon, 06 Dec 2021 07:34:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eulerto.com; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm3; bh=nxd5Ht5QmYEI+LaS+em/prMrQiA+yLB iwWpY0jNVdGw=; b=qktzo3M1V7zY9SnzmifHaOin93VmTxBt7NNqiGWIWQCsli7 9C+ZV7IqR3hTil8+IGAvPElkysF7yYz8adf2m1/uT0Ev+R+gIvKCyW9HdMhAt1Pp AX3QSeD8Y7SnhTULdIPKFzWMuUs7NHz4GNc2H4PwNV3ahyA0iRqI2iEtFc6+8jDF tIU/JrEYI0MyjEtGbRZjAZolaWj/ZGKOAAqu9UJIID/h3qXVGvhPRpyURxs0ms9D NtNBGKivInFxogsTTCrUtqfRU5qCuOFXPWf8dxqoETVNaIRqQibDUodCeTmY6GE8 8Hk30ury9ykWM1pmkuThNlZlJ80cGUnwrHmP5Bw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=nxd5Ht 5QmYEI+LaS+em/prMrQiA+yLBiwWpY0jNVdGw=; b=be3LaEQaTIfD8sdAIueEel B1eTTsNSZyYfRRNYApYEMVNmjGN6oyAUJzRJG/SYcAT0d/Lptegk9zvR90tvzSvO oE36JsV/QxS59kNwFIcAovxfdNsI9t6GT0SgWB00fgP/gHWJHStBrJ6jP/fvgNk8 XOCduF3JwgQHDrhme+/+05jC62HGKiB+soOi+aTxjhBWZjgrVy981ND9AUUjpV2H stRbIT13+sqrI+ocoe0LhjN/Wxjc5DxfmkWmta37+PENltLgYi0QraXV+AdJEbSY uz3ryv69DciYtDFx6564OSoG9w4j8fuqmHYKuVPCJAw8sA5vp6tj0tdsIDSKTcLw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrjeefgdegudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfgfhulhgv rhcuvfgrvhgvihhrrgdfuceovghulhgvrhesvghulhgvrhhtohdrtghomheqnecuggftrf grthhtvghrnhepjeethfeuvdfgffdtteevudeftdejueffkeelveekhfevkeegleefhfej hedtjeegnecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtghomhenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegvuhhlvghrsegvuhhl vghrthhordgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0A719F6006E; Mon, 6 Dec 2021 07:34:15 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4458-g51a91c06b2-fm-20211130.004-g51a91c06 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <49ba49f1-8bdb-40b7-ae9e-f17d88b3afcd@www.fastmail.com> Date: Mon, 06 Dec 2021 09:33:36 -0300 From: "Euler Taveira" To: "Dilip Kumar" Cc: "Peter Smith" , "Amit Kapila" , "Greg Nancarrow" , "houzj.fnst@fujitsu.com" , "vignesh C" , "tanghy.fnst@fujitsu.com" , "Ajin Cherian" , "Rahila Syed" , "Peter Eisentraut" , =?UTF-8?Q?=C3=96nder_Kalac=C4=B1?= , japin , "Michael Paquier" , "David Steele" , "Craig Ringer" , "Amit Langote" , "PostgreSQL Hackers" Subject: Re: row filtering for logical replication Content-Type: multipart/alternative; boundary=47b64c52decf442ab8c27e54b3a82425 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --47b64c52decf442ab8c27e54b3a82425 Content-Type: text/plain On Mon, Dec 6, 2021, at 3:35 AM, Dilip Kumar wrote: > On Mon, Dec 6, 2021 at 6:49 AM Euler Taveira wrote: > > > > On Fri, Dec 3, 2021, at 8:12 PM, Euler Taveira wrote: > > > > PS> I will update the commit message in the next version. I barely changed the > > documentation to reflect the current behavior. I probably missed some changes > > but I will fix in the next version. > > > > I realized that I forgot to mention a few things about the UPDATE behavior. > > Regardless of 0003, we need to define which tuple will be used to evaluate the > > row filter for UPDATEs. We already discussed it circa [1]. This current version > > chooses *new* tuple. Is it the best choice? > > But with 0003, we are using both the tuple for evaluating the row > filter, so instead of fixing 0001, why we don't just merge 0003 with > 0001? I mean eventually, 0003 is doing what is the agreed behavior, > i.e. if just OLD is matching the filter then convert the UPDATE to > DELETE OTOH if only new is matching the filter then convert the UPDATE > to INSERT. Do you think that even we merge 0001 and 0003 then also > there is an open issue regarding which row to select for the filter? Maybe I was not clear. IIUC we are still discussing 0003 and I would like to propose a different default based on the conclusion I came up. If we merged 0003, that's fine; this change will be useless. If we don't or it is optional, it still has its merit. Do we want to pay the overhead to evaluating both tuple for UPDATEs? I'm still processing if it is worth it. If you think that in general the row filter contains the primary key and it is rare to change it, it will waste cycles evaluating the same expression twice. It seems this behavior could be controlled by a parameter. -- Euler Taveira EDB https://www.enterprisedb.com/ --47b64c52decf442ab8c27e54b3a82425 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Mon, Dec 6, = 2021, at 3:35 AM, Dilip Kumar wrote:
On Mon, Dec 6, 2021 at 6:49 AM Euler Taveira &= lt;euler@eulerto.com> wrote:=
>
> On Fri, Dec 3, 2021, at 8:12 PM, = Euler Taveira wrote:
>
> PS> I will= update the commit message in the next version. I barely changed the
=
> documentation to reflect the current behavior. I probabl= y missed some changes
> but I will fix in the next vers= ion.
>
> I realized that I forgot to m= ention a few things about the UPDATE behavior.
> Regard= less of 0003, we need to define which tuple will be used to evaluate the=
> row filter for UPDATEs. We already discussed it circ= a [1]. This current version
> chooses *new* tuple. Is i= t the best choice?

But with 0003, we are us= ing both the tuple for evaluating the row
filter, so inste= ad of fixing 0001, why we don't just merge 0003 with
0001?=   I mean eventually, 0003 is doing what is the agreed behavior,
=
i.e. if just OLD is matching the filter then convert the UPDA= TE to
DELETE OTOH if only new is matching the filter then = convert the UPDATE
to INSERT.  Do you think that even= we merge 0001 and 0003 then also
there is an open issue r= egarding which row to select for the filter?
= Maybe I was not clear. IIUC we are still discussing 0003 and I would lik= e to
propose a different default based on the conclusion I= came up. If we merged
0003, that's fine; this change will= be useless. If we don't or it is optional,
it still has i= ts merit.

Do we want to pay the overhead to= evaluating both tuple for UPDATEs? I'm still
processing i= f it is worth it. If you think that in general the row filter
<= div>contains the primary key and it is rare to change it, it will waste = cycles
evaluating the same expression twice. It seems this= behavior could be
controlled by a parameter.


--
Euler Taveira

--47b64c52decf442ab8c27e54b3a82425--