Horton

Thread

Commits

  1. Use ssup_datum_*_cmp in more places

  2. Perform radix sort on SortTuples with pass-by-value Datums

  3. Specialize tuplesort routines for different kinds of abbreviated keys

  1. [PATCH] Use ssup_datum_*_cmp for int2, oid, and oid8 sort support

    Baji Shaik <baji.pgdev@gmail.com> — 2026-06-03T23:37:09Z

    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], 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] 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]
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
[2]
https://www.postgresql.org/message-id/flat/CA%2BhUKGJ2-eaDqAum5bxhpMNhvuJmRDZxB_Tow0n-gse%2BHG0Yig%40mail.gmail.com
[3] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=b139bd3b6

Thanks,
Baji Shaik

  2. Re: [PATCH] Use ssup_datum_*_cmp for int2, oid, and oid8 sort support

    Michael Paquier <michael@paquier.xyz> — 2026-06-05T03:45:32Z

    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]?

> 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

  3. Re: [PATCH] Use ssup_datum_*_cmp for int2, oid, and oid8 sort support

    Baji Shaik <baji.pgdev@gmail.com> — 2026-06-05T18:35:25Z

    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/

  4. Re: [PATCH] Use ssup_datum_*_cmp for int2, oid, and oid8 sort support

    John Naylor <johncnaylorls@gmail.com> — 2026-07-02T09:00:43Z

    On Thu, Jun 4, 2026 at 6:37 AM Baji Shaik <baji.pgdev@gmail.com> wrote:
> The patch just replaces the comparator assignment and removes the
> now-unused local fastcmp functions.  No behavioral change and the
> helpers produce identical results.

Pushed, thanks for the patch!

-- 
John Naylor
Amazon Web Services