On 07/04/2021 09:00, Heikki Linnakangas wrote:
On 08/03/2021 19:06, Andrey Borodin wrote:
There were numerous GiST-build-related patches in this thread. Yet uncommitted
is a patch with sortsupport routines for btree_gist contrib module.
Here's its version which needs review.
Committed with small fixes. I changed the all functions to use
*GetDatum() and DatumGet*() macros, instead of just comparing Datums
with < and >. Datum is unsigned, while int2, int4, int8 and money are
signed, so that changes the sort order around 0 for those types to be
the same as the picksplit and picksplit functions use. Not a correctness
issue, the sorting only affects the quality of the index, but let's be tidy.
This issue remains:
Reviewing this now again. One thing caught my eye:
+static int
+gbt_bit_sort_build_cmp(Datum a, Datum b, SortSupport ssup)
+{
+ return DatumGetInt32(DirectFunctionCall2(byteacmp,
+
PointerGetDatum(a),
+
PointerGetDatum(b)));
+}
That doesn't quite match the sort order used by the comparison
functions, gbt_bitlt and such. The comparison functions compare the bits
first, and use the length as a tie-breaker. Using byteacmp() will
compare the "bit length" first. However, gbt_bitcmp() also uses
byteacmp(), so I'm a bit confused. So, huh?
Since we used byteacmp() previously for picksplit, too, this is
consistent with the order you got previously. It still seems wrong to me
and should be investigated, but it doesn't need to block this patch.
- Heikki
