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 CACawEhXCWHRT_e+xpHwzXQt6g22ewgQPetA=ZkpG4UX_HJzUGQ@mail.gmail.com
обсуждение исходный текст
Ответ на RE: [Patch] Use *other* indexes on the subscriber when REPLICA IDENTITY is FULL  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
Ответы RE: [Patch] Use *other* indexes on the subscriber when REPLICA IDENTITY is FULL  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
Список pgsql-hackers
Hi Hayato,


BTW, I have doubt that the restriction is not related with your commit.
In other words, if the table has attributes which the datatype is not for operator
class of Btree, we could not use REPLICA IDENTITY FULL. IIUC it is not documented.
Please see attched script to reproduce that. The final DELETE statement cannot be
replicated at the subscriber on my env.


Yes, I agree, it is (and was before my patch as well) un-documented limitation of REPLICA IDENTITY FULL.
And, as far as I can see, my patch actually didn't have any impact on the limitation. The unsupported
cases are still unsupported, but now the same error is thrown in a slightly different place.

I think that is a minor limitation, but maybe should be listed [1]? 

>
For the specific notes you raised about strategy numbers / operator classes, I need to
study a bit :) Though, I'll be available to do that early next week.
>

Thanks! I'm looking forward to see your opinions...

For this one, I did some research in the code, but  I'm not very comfortable with the answer. Still, I wanted to share my observations so that it might be useful for the discussion.

First, I checked if the function get_op_btree_interpretation() could be used here. But, I think that is again btree-only and I couldn't find anything generic that does something similar.

Then, I tried to come up with a SQL query, actually based on the link [2] you shared. I think we should always have an "equality" strategy (e.g., "same", "overlaps", "contains" etc sounds wrong to me).
 
And, it seems btree, hash and brin supports "equal". So, a query like the following seems to provide the list of (index type, strategy_number, data_type) that we might be allowed to use.

  SELECT
    am.amname AS index_type,  amop.amoplefttype::regtype,amop.amoprighttype::regtype,
    op.oprname AS operator,
    amop.amopstrategy AS strategy_number
FROM
    pg_amop amop
JOIN
    pg_am am ON am.oid = amop.amopmethod
JOIN
    pg_operator op ON op.oid = amop.amopopr
WHERE
    (am.amname = 'btree' and amop.amopstrategy = 3) OR
    (am.amname = 'hash' and amop.amopstrategy = 1) OR
    (am.amname = 'brin' and amop.amopstrategy = 3)
ORDER BY
    index_type,
    strategy_number;


What do you think?
 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ranier Vilela
Дата:
Сообщение: Re: Avoid overflow with simplehash
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Avoid overflow with simplehash