[PATCH] Use ssup_datum_*_cmp for int2, oid, and oid8 sort support
Hi,
While auditing nbtcompare.c, I noticed that int2, oid, and oid8
sortsupport functions use custom local fastcmp helpers that are
functionally equivalent to the existing ssup_datum_int32_cmp (for
int2) and ssup_datum_unsigned_cmp (for oid, oid8).
This prevents these types from hitting the radix sort fast path
added in commit ef3c3cf6d02 [1]https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=ef3c3cf6d02, which dispatches based on the
comparator function pointer.
The original 2021-2022 thread that introduced the ssup_datum_*_cmp
helpers (commit 6974924347c, Apr 2022) [2]/messages/by-id/CA+hUKGJ2-eaDqAum5bxhpMNhvuJmRDZxB_Tow0n-gse+HG0Yig@mail.gmail.com covered int4, int8,
timestamp, date, and the abbreviated-key types (text, uuid, macaddr,
inet, bytea). int2 and oid weren't called out in that discussion,
and oid8 didn't exist at the time, it was added in Jan 2026 [3]https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=b139bd3b6
and inherited the custom fastcmp pattern from oid, about a month
before radix sort landed. This patch fills those gaps.
Switching to the existing helpers makes these types eligible for
radix sort. Benchmark (10M-row single-key sort):
Type Before After Speedup
---- ------ ----- -------
int2 2440 ms 1778 ms ~27%
oid 2875 ms 2073 ms ~28%
oid8 2837 ms 2042 ms ~28%
int4 -- 1765 ms (baseline)
int8 -- 2031 ms (baseline)
The patch just replaces the comparator assignment and removes the
now-unused local fastcmp functions. No behavioral change and the
helpers produce identical results.
int2 uses ssup_datum_int32_cmp because there is no int16-specific
helper, every int16 fits losslessly in int32, and int32_cmp is more
efficient than signed_cmp (4-byte radix passes instead of 8).
Other custom fastcmp users in core (float4/float8, varlena types)
cannot be trivially switched due to NaN handling or locale-dependent
comparison, so they are left as-is.
Tested with make check (245/245 pass) and make isolation/check
(128/128 pass).
[1]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=ef3c3cf6d02
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=ef3c3cf6d02
[2]: /messages/by-id/CA+hUKGJ2-eaDqAum5bxhpMNhvuJmRDZxB_Tow0n-gse+HG0Yig@mail.gmail.com
/messages/by-id/CA+hUKGJ2-eaDqAum5bxhpMNhvuJmRDZxB_Tow0n-gse+HG0Yig@mail.gmail.com
[3]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=b139bd3b6
Thanks,
Baji Shaik
Attachments:
0001-Use-ssup_datum_-_cmp-for-int2-oid-and-oid8-sort-supp.patchapplication/octet-stream; name=0001-Use-ssup_datum_-_cmp-for-int2-oid-and-oid8-sort-supp.patchDownload+3-41
On Wed, Jun 03, 2026 at 06:37:09PM -0500, Baji Shaik wrote:
int2 uses ssup_datum_int32_cmp because there is no int16-specific
helper, every int16 fits losslessly in int32, and int32_cmp is more
efficient than signed_cmp (4-byte radix passes instead of 8).
That's nice for such a simple change. That seems correct to me.
Could you add that to the next commit fest please at [1]https://commitfest.postgresql.org/59/ -- Michael?
Other custom fastcmp users in core (float4/float8, varlena types)
cannot be trivially switched due to NaN handling or locale-dependent
comparison, so they are left as-is.
Nope, we cannot do that.
[1]: https://commitfest.postgresql.org/59/ -- Michael
--
Michael
On Thu, Jun 4, 2026 at 10:45 PM Michael Paquier <michael@paquier.xyz> wrote:
That's nice for such a simple change. That seems correct to me.
Could you add that to the next commit fest please at [1]?
Thanks for the review.
Added to the commitfest: https://commitfest.postgresql.org/patch/6851/