| From: | Önder Kalacı <onderkalaci(at)gmail(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [Patch] Use *other* indexes on the subscriber when REPLICA IDENTITY is FULL |
| Date: | 2023-07-10 14:13:42 |
| Message-ID: | CACawEhUmjqXXRzVAYhSNZEDCX3Sig5srSfu8=eQdQt+c_HSDhg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Melih Mutlu | 2023-07-10 14:22:58 | Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication |
| Previous Message | Peter Eisentraut | 2023-07-10 14:05:18 | Re: Exclusion constraints on partitioned tables |