Re: [Patch] Use *other* indexes on the subscriber when REPLICA IDENTITY is FULL

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: [Patch] Use *other* indexes on the subscriber when REPLICA IDENTITY is FULL
Дата
Msg-id CAA4eK1J1D2kWTBGnWjA032=k9Bg4Q_hbv2+xVg1t3DCpszi6ew@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [Patch] Use *other* indexes on the subscriber when REPLICA IDENTITY is FULL  (Önder Kalacı <onderkalaci@gmail.com>)
Ответы RE: [Patch] Use *other* indexes on the subscriber when REPLICA IDENTITY is FULL  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
Список 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 по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: Performance degradation on concurrent COPY into a single relation in PG16.
Следующее
От: "suyu.cmj"
Дата:
Сообщение: Got FATAL in lock_twophase_recover() during recovery