(Replying to old thread, because I happened to spot this while looking
at David Geier's proposal at:
https://www.postgresql.org/message-id/5d366878-2007-4d31-861e-19294b7a583b%40gmail.com)
On 07/01/2025 13:59, Tomas Vondra wrote:
> On 1/6/25 20:13, Matthias van de Meent wrote:
>>> GinBufferInit
>>
>> This seems to depend on the btree operator classes to get sortsupport
>> functions, bypassing the GIN compare support function (support
>> function 1) and adding a dependency on the btree opclasses for
>> indexable types. This can cause "bad" ordering, or failure to build
>> the index when the parallel path is chosen and no default btree
>> opclass is defined for the type. I think it'd be better if we allowed
>> users to specify which sortsupport function to use, or at least use
>> the correct compare function when it's defined on the attribute's
>> operator class.
>
> Good point! I fixed this by copying the logic from initGinState.
I think tuplesort_begin_index_gin() has the same issue. It does this to
look up the comparison function:
/*
* Look for an ordering for the index key data type, and then the sort
* support function.
*/
typentry = lookup_type_cache(att->atttypid, TYPECACHE_LT_OPR);
PrepareSortSupportFromOrderingOp(typentry->lt_opr, sortKey);
That also looks up the key type's b-tree operator rather than the GIN
opclass's compare function.
- Heikki
