| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | Önder Kalacı <onderkalaci(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-11 02:33:14 |
| Message-ID: | CAA4eK1J1D2kWTBGnWjA032=k9Bg4Q_hbv2+xVg1t3DCpszi6ew@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jul 10, 2023 at 7:43 PM Önder Kalacı <onderkalaci(at)gmail(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | suyu.cmj | 2023-07-11 02:35:15 | Got FATAL in lock_twophase_recover() during recovery |
| Previous Message | Masahiko Sawada | 2023-07-11 02:32:59 | Re: Performance degradation on concurrent COPY into a single relation in PG16. |