Re: Parallel CREATE INDEX for GIN indexes

On Mon, 12 Jan 2026 at 03:20, Tomas Vondra <tomas(at)vondra(dot)me> wrote:
>
> 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
>

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.

All of this is not eager, just posing my thoughts.

[1] https://coverage.postgresql.org/src/backend/access/gin/gininsert.c.gcov.html
[0] https://coverage.postgresql.org/src/backend/access/nbtree/nbtsort.c.gcov.html

--
Best regards,
Kirill Reshke