Re: tuple radix sort
cca5507 <cca5507@qq.com>
From: cca5507 <cca5507@qq.com>
To: John Naylor <johncnaylorls@gmail.com>
Cc: zengman <zengman@halodbtech.com>, pgsql-hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-04-08T08:20:47Z
Lists: pgsql-hackers
> I also thought we should change this cast:
>
> if (ssup->comparator == ssup_datum_signed_cmp)
> {
> - norm_datum1 = orig + ((uint64) PG_INT64_MAX) + 1;
> + norm_datum1 = orig + (Int64GetDatum(PG_INT64_MAX)) + 1;
> }
>
> Upthread you mention something else about treating Datum as an
> integer, but I'm not sure if this is what you meant since you didn't
> say. If you have concrete suggestions, feel free to share them.
I think we can keep it as is now. The idea of don't treat datum as an integer comes from:
https://www.postgresql.org/message-id/flat/8246d7ff-f4b7-4363-913e-827dadfeb145%40eisentraut.org
--
Regards,
ChangAo Chen
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Cosmetic fixes for radix sort
- ca9807dfec5b 19 (unreleased) landed
-
Skip common prefixes during radix sort
- f6bd9f0fe25a 19 (unreleased) landed
-
Perform radix sort on SortTuples with pass-by-value Datums
- ef3c3cf6d021 19 (unreleased) landed
-
Grab the low-hanging fruit from forcing sizeof(Datum) to 8.
- 6aebedc38497 19 (unreleased) cited
-
Add missing Datum conversions
- ff89e182d420 19 (unreleased) cited