MIME-Version: 1.0
From: Baji Shaik <baji.pgdev@gmail.com>
Date: Wed, 3 Jun 2026 18:37:09 -0500
Message-ID: 
 <CA+fm-RMyLC94NfrxCh273+dKs44U0ZJjRczznvzvgw=KtpPNVw@mail.gmail.com>
Subject: [PATCH] Use ssup_datum_*_cmp for int2, oid, and oid8 sort support
To: pgsql-hackers@lists.postgresql.org
Cc: john.naylor@postgresql.org, michael@paquier.xyz
Content-Type: multipart/mixed; boundary="000000000000b8ace6065361e89f"
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2Bfm-RMyLC94NfrxCh273%2BdKs44U0ZJjRczznvzvgw%3DKtpPNVw%40mail.gmail.com>
Precedence: bulk

--000000000000b8ace6065361e89f
Content-Type: multipart/alternative; boundary="000000000000b8ace5065361e89d"

--000000000000b8ace5065361e89d
Content-Type: text/plain; charset="UTF-8"

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

--000000000000b8ace5065361e89d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<br><br>While auditing nbtcompare.c, I noticed that int=
2, oid, and oid8<br>sortsupport functions use custom local fastcmp helpers =
that are<br>functionally equivalent to the existing ssup_datum_int32_cmp (f=
or<br>int2) and ssup_datum_unsigned_cmp (for oid, oid8).<br><br>This preven=
ts these types from hitting the radix sort fast path<br>added in commit ef3=
c3cf6d02 [1], which dispatches based on the<br>comparator function pointer.=
<br><br>The original 2021-2022 thread that introduced the ssup_datum_*_cmp<=
br>helpers (commit 6974924347c, Apr 2022) [2] covered int4, int8,<br>timest=
amp, date, and the abbreviated-key types (text, uuid, macaddr,<br>inet, byt=
ea). =C2=A0int2 and oid weren&#39;t called out in that discussion,<br>and o=
id8 didn&#39;t exist at the time, it was added in Jan 2026 [3]<br>and inher=
ited the custom fastcmp pattern from oid, about a month<br>before radix sor=
t landed.=C2=A0 This patch fills those gaps.<br><br>Switching to the existi=
ng helpers makes these types eligible for<br>radix sort.=C2=A0 Benchmark (1=
0M-row single-key sort):<br><br>=C2=A0 Type =C2=A0 =C2=A0 Before =C2=A0 =C2=
=A0After =C2=A0 =C2=A0 Speedup<br>=C2=A0 ---- =C2=A0 =C2=A0 ------ =C2=A0 =
=C2=A0----- =C2=A0 =C2=A0 -------<br>=C2=A0 int2 =C2=A0 =C2=A0 2440 ms =C2=
=A0 1778 ms =C2=A0 ~27%<br>=C2=A0 oid =C2=A0 =C2=A0 =C2=A02875 ms =C2=A0 20=
73 ms =C2=A0 ~28%<br>=C2=A0 oid8 =C2=A0 =C2=A0 2837 ms =C2=A0 2042 ms =C2=
=A0 ~28%<br>=C2=A0 int4 =C2=A0 =C2=A0 -- =C2=A0 =C2=A0 =C2=A0 =C2=A01765 ms=
 =C2=A0 (baseline)<br>=C2=A0 int8 =C2=A0 =C2=A0 -- =C2=A0 =C2=A0 =C2=A0 =C2=
=A02031 ms =C2=A0 (baseline)<br><br>The patch just replaces the comparator =
assignment and removes the<br>now-unused local fastcmp functions.=C2=A0 No =
behavioral change and the<br>helpers produce identical results.<br><br>int2=
 uses ssup_datum_int32_cmp because there is no int16-specific<br>helper, ev=
ery int16 fits losslessly in int32, and int32_cmp is more<br>efficient than=
 signed_cmp (4-byte radix passes instead of 8).<br><br>Other custom fastcmp=
 users in core (float4/float8, varlena types)<br>cannot be trivially switch=
ed due to NaN handling or locale-dependent<br>comparison, so they are left =
as-is.<br><br>Tested with make check (245/245 pass) and make isolation/chec=
k<br>(128/128 pass).<br><br>[1] <a href=3D"https://git.postgresql.org/gitwe=
b/?p=3Dpostgresql.git;a=3Dcommit;h=3Def3c3cf6d02">https://git.postgresql.or=
g/gitweb/?p=3Dpostgresql.git;a=3Dcommit;h=3Def3c3cf6d02</a><br>[2] <a href=
=3D"https://www.postgresql.org/message-id/flat/CA%2BhUKGJ2-eaDqAum5bxhpMNhv=
uJmRDZxB_Tow0n-gse%2BHG0Yig%40mail.gmail.com">https://www.postgresql.org/me=
ssage-id/flat/CA%2BhUKGJ2-eaDqAum5bxhpMNhvuJmRDZxB_Tow0n-gse%2BHG0Yig%40mai=
l.gmail.com</a><br>[3] <a href=3D"https://git.postgresql.org/gitweb/?p=3Dpo=
stgresql.git;a=3Dcommit;h=3Db139bd3b6">https://git.postgresql.org/gitweb/?p=
=3Dpostgresql.git;a=3Dcommit;h=3Db139bd3b6</a><br><div><br></div><div>Thank=
s,<br>Baji Shaik</div></div>

--000000000000b8ace5065361e89d--

--000000000000b8ace6065361e89f
Content-Type: application/octet-stream;
	name="0001-Use-ssup_datum_-_cmp-for-int2-oid-and-oid8-sort-supp.patch"
Content-Disposition: attachment;
	filename="0001-Use-ssup_datum_-_cmp-for-int2-oid-and-oid8-sort-supp.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_mpyopil30>
X-Attachment-Id: f_mpyopil30

RnJvbSBlMjNmYzFjOWEyODQzNWY1NmNiYjI0ZTZmYzIzYzg1ZGRlNDA2MmRhIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBCYWppIFNoYWlrIDxiYWppLnBnZGV2QGdtYWlsLmNvbT4KRGF0
ZTogV2VkLCAyNyBNYXkgMjAyNiAwMTo0ODowNSArMDAwMApTdWJqZWN0OiBbUEFUQ0hdIFVzZSBz
c3VwX2RhdHVtXypfY21wIGZvciBpbnQyLCBvaWQgYW5kIG9pZDggc29ydCBzdXBwb3J0CgpUaGUg
aW50Miwgb2lkLCBhbmQgb2lkOCBzb3J0c3VwcG9ydCBmdW5jdGlvbnMgdXNlZCBjdXN0b20gZmFz
dGNtcApoZWxwZXJzIHRoYXQgYXJlIGZ1bmN0aW9uYWxseSBlcXVpdmFsZW50IHRvIHNzdXBfZGF0
dW1faW50MzJfY21wIChmb3IKaW50MikgYW5kIHNzdXBfZGF0dW1fdW5zaWduZWRfY21wIChmb3Ig
b2lkLCBvaWQ4KS4gIFRoaXMgcHJldmVudGVkCnRoZXNlIHR5cGVzIGZyb20gdXNpbmcgdGhlIHJh
ZGl4IHNvcnQgZmFzdCBwYXRoIGFkZGVkIGluIGNvbW1pdAplZjNjM2NmNmQwMiwgd2hpY2ggZGlz
cGF0Y2hlcyBiYXNlZCBvbiB0aGUgY29tcGFyYXRvciBwb2ludGVyLgoKU3dpdGNoaW5nIHRvIHRo
ZSBleGlzdGluZyBoZWxwZXJzIG1ha2VzIGludDIsIG9pZCwgYW5kIG9pZDggY29sdW1uCnNvcnRz
IGVsaWdpYmxlIGZvciByYWRpeCBzb3J0LCBicmluZ2luZyB0aGVtIHRvIHBhcml0eSB3aXRoIGlu
dDQvaW50OApiYXNlbGluZS4KCkF1dGhvcjogQmFqaSBTaGFpayA8YmFqaS5wZ2RldkBnbWFpbC5j
b20+ClJldmlld2VkLWJ5OgpEaXNjdXNzaW9uOgotLS0KIHNyYy9iYWNrZW5kL2FjY2Vzcy9uYnRy
ZWUvbmJ0Y29tcGFyZS5jIHwgNDMgKystLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KIDEgZmlsZSBj
aGFuZ2VkLCAzIGluc2VydGlvbnMoKyksIDQwIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3Ny
Yy9iYWNrZW5kL2FjY2Vzcy9uYnRyZWUvbmJ0Y29tcGFyZS5jIGIvc3JjL2JhY2tlbmQvYWNjZXNz
L25idHJlZS9uYnRjb21wYXJlLmMKaW5kZXggMWQzNDMzNzdlOTguLjc5NWZkZWQ0OWQzIDEwMDY0
NAotLS0gYS9zcmMvYmFja2VuZC9hY2Nlc3MvbmJ0cmVlL25idGNvbXBhcmUuYworKysgYi9zcmMv
YmFja2VuZC9hY2Nlc3MvbmJ0cmVlL25idGNvbXBhcmUuYwpAQCAtMTM0LDIxICsxMzQsMTIgQEAg
YnRpbnQyY21wKFBHX0ZVTkNUSU9OX0FSR1MpCiAJUEdfUkVUVVJOX0lOVDMyKChpbnQzMikgYSAt
IChpbnQzMikgYik7CiB9CiAKLXN0YXRpYyBpbnQKLWJ0aW50MmZhc3RjbXAoRGF0dW0geCwgRGF0
dW0geSwgU29ydFN1cHBvcnQgc3N1cCkKLXsKLQlpbnQxNgkJYSA9IERhdHVtR2V0SW50MTYoeCk7
Ci0JaW50MTYJCWIgPSBEYXR1bUdldEludDE2KHkpOwotCi0JcmV0dXJuIChpbnQpIGEgLSAoaW50
KSBiOwotfQotCiBEYXR1bQogYnRpbnQyc29ydHN1cHBvcnQoUEdfRlVOQ1RJT05fQVJHUykKIHsK
IAlTb3J0U3VwcG9ydCBzc3VwID0gKFNvcnRTdXBwb3J0KSBQR19HRVRBUkdfUE9JTlRFUigwKTsK
IAotCXNzdXAtPmNvbXBhcmF0b3IgPSBidGludDJmYXN0Y21wOworCXNzdXAtPmNvbXBhcmF0b3Ig
PSBzc3VwX2RhdHVtX2ludDMyX2NtcDsKIAlQR19SRVRVUk5fVk9JRCgpOwogfQogCkBAIC00MzEs
MjYgKzQyMiwxMiBAQCBidG9pZGNtcChQR19GVU5DVElPTl9BUkdTKQogCQlQR19SRVRVUk5fSU5U
MzIoQV9MRVNTX1RIQU5fQik7CiB9CiAKLXN0YXRpYyBpbnQKLWJ0b2lkZmFzdGNtcChEYXR1bSB4
LCBEYXR1bSB5LCBTb3J0U3VwcG9ydCBzc3VwKQotewotCU9pZAkJCWEgPSBEYXR1bUdldE9iamVj
dElkKHgpOwotCU9pZAkJCWIgPSBEYXR1bUdldE9iamVjdElkKHkpOwotCi0JaWYgKGEgPiBiKQot
CQlyZXR1cm4gQV9HUkVBVEVSX1RIQU5fQjsKLQllbHNlIGlmIChhID09IGIpCi0JCXJldHVybiAw
OwotCWVsc2UKLQkJcmV0dXJuIEFfTEVTU19USEFOX0I7Ci19Ci0KIERhdHVtCiBidG9pZHNvcnRz
dXBwb3J0KFBHX0ZVTkNUSU9OX0FSR1MpCiB7CiAJU29ydFN1cHBvcnQgc3N1cCA9IChTb3J0U3Vw
cG9ydCkgUEdfR0VUQVJHX1BPSU5URVIoMCk7CiAKLQlzc3VwLT5jb21wYXJhdG9yID0gYnRvaWRm
YXN0Y21wOworCXNzdXAtPmNvbXBhcmF0b3IgPSBzc3VwX2RhdHVtX3Vuc2lnbmVkX2NtcDsKIAlQ
R19SRVRVUk5fVk9JRCgpOwogfQogCkBAIC01MTMsMjYgKzQ5MCwxMiBAQCBidG9pZDhjbXAoUEdf
RlVOQ1RJT05fQVJHUykKIAkJUEdfUkVUVVJOX0lOVDMyKEFfTEVTU19USEFOX0IpOwogfQogCi1z
dGF0aWMgaW50Ci1idG9pZDhmYXN0Y21wKERhdHVtIHgsIERhdHVtIHksIFNvcnRTdXBwb3J0IHNz
dXApCi17Ci0JT2lkOAkJYSA9IERhdHVtR2V0T2JqZWN0SWQ4KHgpOwotCU9pZDgJCWIgPSBEYXR1
bUdldE9iamVjdElkOCh5KTsKLQotCWlmIChhID4gYikKLQkJcmV0dXJuIEFfR1JFQVRFUl9USEFO
X0I7Ci0JZWxzZSBpZiAoYSA9PSBiKQotCQlyZXR1cm4gMDsKLQllbHNlCi0JCXJldHVybiBBX0xF
U1NfVEhBTl9COwotfQotCiBEYXR1bQogYnRvaWQ4c29ydHN1cHBvcnQoUEdfRlVOQ1RJT05fQVJH
UykKIHsKIAlTb3J0U3VwcG9ydCBzc3VwID0gKFNvcnRTdXBwb3J0KSBQR19HRVRBUkdfUE9JTlRF
UigwKTsKIAotCXNzdXAtPmNvbXBhcmF0b3IgPSBidG9pZDhmYXN0Y21wOworCXNzdXAtPmNvbXBh
cmF0b3IgPSBzc3VwX2RhdHVtX3Vuc2lnbmVkX2NtcDsKIAlQR19SRVRVUk5fVk9JRCgpOwogfQog
Ci0tIAoyLjUwLjEKCg==
--000000000000b8ace6065361e89f--