From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> |
Cc: | Önder Kalacı <onderkalaci(at)gmail(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 09:54:04 |
Message-ID: | CAA4eK1Jv8+8rax-bejd3Ej+T2fG3tuqP8v89byKCBPVQj9C9pg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 26, 2023 at 7:14 PM Hayato Kuroda (Fujitsu)
<kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
>
> Thank you for giving comments! The author's comment is quite helpful for us.
>
> >
> When I last dealt with the same issue, I was examining it from a slightly broader perspective. I think
> my conclusion was that RelationFindReplTupleByIndex() is designed for the constraints of UNIQUE INDEX
> and Primary Key.
> >
>
> I see. IIUC that's why you have added tuples_equal() in the RelationFindReplTupleByIndex().
>
> >
> I think we should also be mindful about tuples_equal() function. When an index returns more than
> one tuple, we rely on tuples_equal() function to make sure non-relevant tuples are skipped.
>
> For btree indexes, it was safe to rely on that function as the columns that are indexed using btree
> always have equality operator. I think we can safely assume the same for hash indexes.
>
> However, say we indexed "point" type using "gist" index. Then, if we let this logic to kick in,
> I think tuples_equal() would fail saying that there is no equality operator exists.
> >
>
> Good point. Actually I have tested for "point" datatype but it have not worked well.
> Now I understand the reason.
> It seemed that when TYPECACHE_EQ_OPR_FINFO is reuqesed to lookup_type_cache(),
> it could return valid value only if the datatype has operator class for Btree or Hash.
> So tuples_equal() might not be able to use if tuples have point box circle types.
>
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?
--
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2023-07-10 09:56:43 | Re: Request for comment on setting binary format output per session |
Previous Message | Sergey Shinderuk | 2023-07-10 09:39:52 | Re: gcc -Wclobbered in PostgresMain |