Re: Parallel CREATE INDEX for GIN indexes

(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