public inbox for [email protected]
help / color / mirror / Atom feedFrom: Amit Kapila <[email protected]>
To: Önder Kalacı <[email protected]>
Cc: Marco Slot <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: [PATCH] Use indexes on the subscriber when REPLICA IDENTITY is full on the publisher
Date: Mon, 30 Jan 2023 18:46:07 +0530
Message-ID: <CAA4eK1L6P8hM+17fNyWogSnueTJebvZUX7YseL54HSFpX_0m_A@mail.gmail.com> (raw)
In-Reply-To: <CACawEhUxEfVr64ywC0sj7nDwFg=vR30qehNoqSDcx6VV2=B_Lw@mail.gmail.com>
References: <OSZPR01MB63105BD4B03B3C1FBFCC7E6CFD249@OSZPR01MB6310.jpnprd01.prod.outlook.com>
<CACawEhWdoiaXwKjn5ZfAKF_Toz=t1aqT1ewHmJLRnXmKOQKwyg@mail.gmail.com>
<OS3PR01MB62754E945BD95A9B2A1164789E289@OS3PR01MB6275.jpnprd01.prod.outlook.com>
<CACawEhXBtt9aMoU0j6funj-s+CW+e8HMFCGz30gyEwLazXB_1w@mail.gmail.com>
<OSZPR01MB63109FF52120649EECACC7AEFD2A9@OSZPR01MB6310.jpnprd01.prod.outlook.com>
<CACawEhUUHcSVhp-bODSAnYNUQHY=4gvY29DXM=yuphgrkcqqmQ@mail.gmail.com>
<CACawEhX6TvX+j8EpcpCKvnMGao8Gcp8W43Sgc87pg9o6-Xbf2Q@mail.gmail.com>
<[email protected]>
<CACawEhV68Ry7BGJV150xsUskJPa88rpOf3zo_OcA_MpSWGQobQ@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<CAFMSG9E7_JgnaBj1f_jU4dEmOnL=K6UyBAPR7eZ0NukUcR2L9g@mail.gmail.com>
<CACawEhUxEfVr64ywC0sj7nDwFg=vR30qehNoqSDcx6VV2=B_Lw@mail.gmail.com>
On Fri, Jan 27, 2023 at 6:32 PM Önder Kalacı <[email protected]> wrote:
>>
>> I suppose the options are:
>> 1. use regular planner uniformly
>> 2. use regular planner only when there's no replica identity (or configurable?)
>> 3. only use low-level functions
>> 4. keep using sequential scans for every single updated row
>> 5. introduce a hidden logical row identifier in the heap that is guaranteed unique within a table and can be used as a replica identity when no unique index exists
>
>
> One other option I considered was to ask the index explicitly on the subscriber side from the user when REPLICA IDENTITY is FULL. But, it is a pretty hard choice for any user, even a planner sometimes fails to pick the right index :) Also, it is probably controversial to change any of the APIs for this purpose?
>
I agree that it won't be a very convenient option for the user but how
about along with asking for an index from the user (when the user
didn't provide an index), we also allow to make use of any unique
index over a subset of the transmitted columns, and if there's more
than one candidate index pick any one. Additionally, we can allow
disabling the use of an index scan for this particular case. If we are
too worried about API change for allowing users to specify the index
then we can do that later or as a separate patch.
> I'd be happy to hear from more experienced hackers on the trade-offs for the above, and I'd be open to work on that if there is a clear winner. For me (3) is a decent solution for the problem.
>
From the discussion above it is not very clear that adding maintenance
costs in this area is worth it even though that can give better
results as far as this feature is concerned.
--
With Regards,
Amit Kapila.
view thread (18+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: [PATCH] Use indexes on the subscriber when REPLICA IDENTITY is full on the publisher
In-Reply-To: <CAA4eK1L6P8hM+17fNyWogSnueTJebvZUX7YseL54HSFpX_0m_A@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox