On Mon, Sep 1, 2025 at 8:13 AM Tatsuo Ishii <ishii@postgresql.org> wrote:
>
> > Branch alignment surely shouldn't matter in a function that is called
> > once per query?
>
> According to my test, it seems using unlikely() makes a small but
> non-negligible performance improvement over the code without
> unlikely() for small queries.
>
> Test method: Apply the latest patch (it needs rebasing) to master.
> Disable debug_print_raw_parse. Run pgbench with following arguments:
>
> $ pgbench -c 10 -j 10 -f bench.sql -T 60 test
> cat bench.sql
> SELECT 1;
>
> I ran pgbench 3 times and here's the results:
>
> case 1: with patch (unlikely() is used)
> tps = 63279.645198 (without initial connection time)
> tps = 62385.016698 (without initial connection time)
> tps = 62950.431703 (without initial connection time)
> average: 62871.697866
>
> case 2: with patch (unlikely() is not used)
> tps = 62462.798551 (without initial connection time)
> tps = 63085.646278 (without initial connection time)
> tps = 61361.373551 (without initial connection time)
> average: 62303.272793
>
> case 1 (62871.697866) / case 2 (62303.272793) = 1.009213
>
> It seems case 1 (unlikely() is used) is about 0.9% faster than case
> 2
The individual runs have quite a bit of variation.
It's good to cross check results against known facts. If my napkin
math is right, a ~1% speedup for ~60ktps/s amounts to saving ~160ns
per query. It's not plausible that forcing the compiler's hand for
this branch would save several hundred clock cycles.
To be fair I tried to reproduce and found only noise-level differences:
master: 61553
case 1: 61423
case 2: 61647
--
John Naylor
Amazon Web Services
