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