Use bsearch() instead of a manual binary search in syscache.c
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t52621psql -h localhost -U postgresBuilt from patchset v1 (message #1), August 24, 2026 at 02:23 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t52621_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t52621_1 && git checkout t52621_1Patchset v1 (message #1) is on t52621_1
Hi, hackers!
I make a patch for the $subject, which make the code simpler, thoughts?
--
Regards,
ChangAo Chen
cca5507 <cca5507@qq.com> wrote:
I make a patch for the $subject, which make the code simpler, thoughts?
I proposed something like that earlier [1]/messages/by-id/36977.1720623613@antos but did not get too far. The short
discussion might be useful for you though.
[1]: /messages/by-id/36977.1720623613@antos
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
On Sun, Nov 9, 2025 at 1:12 AM Antonin Houska <ah@cybertec.at> wrote:
cca5507 <cca5507@qq.com> wrote:
I make a patch for the $subject, which make the code simpler, thoughts?
I proposed something like that earlier [1] but did not get too far. The short
discussion might be useful for you though.
One factor is that libc bsearch() implementations might not all be
header-only and inlineable. I vaguely recall that being discussed in
some round of hacking on qsort() and qunique().
Thomas Munro <thomas.munro@gmail.com> writes:
One factor is that libc bsearch() implementations might not all be
header-only and inlineable. I vaguely recall that being discussed in
some round of hacking on qsort() and qunique().
I'm quite certain that years ago we determined that bsearch()
was slower than a manually written-out loop, probably because of
exactly the point that the comparisons would be inline. Don't
know whether modern compilers have changed that conclusion.
There are places where we wouldn't care about such microscopic
performance details, but I think syscache.c is not one of them.
regards, tom lane
On Sun, Nov 9, 2025 at 6:01 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
I'm quite certain that years ago we determined that bsearch()
was slower than a manually written-out loop, probably because of
exactly the point that the comparisons would be inline. Don't
know whether modern compilers have changed that conclusion.
It looks like glibc's version is inlined, but others I checked aren't.
There are places where we wouldn't care about such microscopic
performance details, but I think syscache.c is not one of them.
So we'd probably need our own inline function to keep the playing
field level. Some tweaked algorithms[1]https://github.com/scandum/binary_search are also said to speed up
small integer tables, Unicode tables etc.
Hi,
Thanks for the explanation which helps me a lot!
The bsearch() got inlined according to compiler explorer:
https://godbolt.org/z/1x69zGMcn
So we'd probably need our own inline function to keep the playing
field level. Some tweaked algorithms[1] are also said to speed up
small integer tables, Unicode tables etc.
How about add a pg_bsearch() and #define bsearch(a,b,c,d,e) pg_bsearch(a,b,c,d,e) to use it?
--
Regards,
ChangAo Chen