Re: Parallel CREATE INDEX for GIN indexes

On 1/11/26 21:31, Heikki Linnakangas wrote:
> (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.
> 

Thanks for noticing this, I'll get this fixed next week.

Funny, you noticed that almost exactly one year after I fixed the other
incorrect place in the patch ;-)


regards

-- 
Tomas Vondra