(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
