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

From Önder Kalacı
Subject Re: [Patch] Use *other* indexes on the subscriber when REPLICA IDENTITY is FULL
Date
Msg-id CACawEhUmjqXXRzVAYhSNZEDCX3Sig5srSfu8=eQdQt+c_HSDhg@mail.gmail.com
Whole thread Raw
In response to Re: [Patch] Use *other* indexes on the subscriber when REPLICA IDENTITY is FULL  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: [Patch] Use *other* indexes on the subscriber when REPLICA IDENTITY is FULL
List pgsql-hackers
Hi,

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.

I think if someone one day works on supporting primary keys using other index types, we can use it here :p

Thanks,
Onder

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Exclusion constraints on partitioned tables
Next
From: Melih Mutlu
Date:
Subject: Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication