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

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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Exclusion constraints on partitioned tables
Следующее
От: Melih Mutlu
Дата:
Сообщение: Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication