On Mon, 12 Jan 2026 at 03:20, Tomas Vondra <[email protected]> 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
