Re: Parallel CREATE INDEX for GIN indexes

On 1/16/26 19:03, Tomas Vondra wrote:
> 
> On 1/15/26 06:08, Kirill Reshke wrote:
>> ...
>>>>
>>>> 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 ;-)
>>>
> 
> The attached 0001 should fix this. I'm wondering what kinds of issues it
> might cause, and if we need to mention that in release notes. AFAICS it
> would cause trouble if (a) there's no b-tree opclass, in which case the
> tuplesort_begin_index_gin() errors out, or (b) the btree/gin opclasses
> disagree on ordering (or rather equality).
> 
> AFAIK we haven't heard anything about index builds failing on 18, and
> with both btree/gin opclasses it seems unlikely they'd define equality
> differently. Maybe I'm missing something.
> 
>>
>>
>> I was looking at code coverage for GIN indexes [1] and noticed that
>> Parallel GIN build is not covered in the regression test. Btree
>> parallel build (_bt_begin_parallel function for example at[0]) is
>> covered. I did not find any btree-parallel-build dedicated test, looks
>> like this is covered by accident, from write_paralle, partition_prune
>> and other regression tests.
>>
>> So, maybe add some tests here? Also, I wonder what regression sql file
>> to use, or maybe create a new one.
>>
> 
> Fair point. Someone pinged me about this coverage issue a while back,
> but it completely slipped my mind. 0002 tweaks two places in regression
> tests to build the GIN index in parallel. Which for me seems to improve
> the coverage quite a bit. It's not perfect, because it's still not a lot
> of data, which means some code is impossible to hit (e.g. it'll not hit
> trimming).
> 

Pushed both patches and backpatched to 18.


Thanks!

-- 
Tomas Vondra