On Mon, Jun 26, 2023 at 7:14 PM Hayato Kuroda (Fujitsu)
<kuroda.hayato@fujitsu.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.