Re: [PATCH] Use indexes on the subscriber when REPLICA IDENTITY is full on the publisher - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [PATCH] Use indexes on the subscriber when REPLICA IDENTITY is full on the publisher
Date
Msg-id 20230307195119.ars36cx6gwqftoen@awork3.anarazel.de
Whole thread Raw
In response to Re: [PATCH] Use indexes on the subscriber when REPLICA IDENTITY is full on the publisher  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
Hi,

On 2023-03-07 08:22:45 +0530, Amit Kapila wrote:
> On Tue, Mar 7, 2023 at 1:34 AM Andres Freund <andres@anarazel.de> wrote:
> > I think even as-is it's reasonable to just use it. The sequential scan
> > approach is O(N^2), which, uh, is not good. And having an index over thousands
> > of non-differing values will generally perform badly, not just in this
> > context.
> >
> Yes, it is true that generally also index scan with a lot of
> duplicates may not perform well but during the scan, we do costing to
> ensure such cases and may prefer other index or sequence scan. Then we
> have "enable_indexscan" GUC that the user can use if required. So, I
> feel it is better to have a knob to disallow usage of such indexes and
> the default would be to use an index, if available.

It just feels like we're optimizing for an irrelevant case here. If we add
GUCs for irrelevant things like this we'll explode the number of GUCs even
faster than we already are.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Add shared buffer hits to pg_stat_io
Next
From: Peter Eisentraut
Date:
Subject: Re: Add support for unit "B" to pg_size_pretty()