Re: [Patch] Use *other* indexes on the subscriber when REPLICA IDENTITY is FULL - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [Patch] Use *other* indexes on the subscriber when REPLICA IDENTITY is FULL
Date
Msg-id CAA4eK1J1D2kWTBGnWjA032=k9Bg4Q_hbv2+xVg1t3DCpszi6ew@mail.gmail.com
Whole thread Raw
In response to Re: [Patch] Use *other* indexes on the subscriber when REPLICA IDENTITY is FULL  (Önder Kalacı <onderkalaci@gmail.com>)
Responses RE: [Patch] Use *other* indexes on the subscriber when REPLICA IDENTITY is FULL
List pgsql-hackers
On Mon, Jul 10, 2023 at 7:43 PM Önder Kalacı <onderkalaci@gmail.com> wrote:
>
>> I also think so. If this is true, how can we think of supporting
>> indexes other than hash like GiST, and SP-GiST as mentioned by you in
>> your latest email? As per my understanding if we don't have PK or
>> replica identity then after the index scan, we do tuples_equal which
>> will fail for GIST or SP-GIST. Am, I missing something?
>
>
> I also don't think we can support anything other than btree, hash and brin as those lack equality operators.
>
> And, for BRIN, Hayato brought up the amgettuple issue, which is fair. So, overall, as far as I can see, we can
> easily add hash indexes but all others are either very hard to add or not possible.
>

Agreed. So, let's update the patch with comments indicating the
challenges for supporting the other index types than btree and hash.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Performance degradation on concurrent COPY into a single relation in PG16.
Next
From: "suyu.cmj"
Date:
Subject: Got FATAL in lock_twophase_recover() during recovery