Re: pg_stat_io_histogram

Hi,

On 2026-01-28 12:12:10 +0100, Jakub Wartak wrote:
> On Tue, Jan 27, 2026 at 1:06 PM Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>
> > Not yet, I first wanted to hear if I'm not sailing into some plain stupid
> > direction somewhere with this idea or implementation (e.g.
> > that INSTR_TIME_GET_MICROSEC() was a really stupid omission from my side).
> >
> > I'll try to perform this test overhead measurement hopefully with v3 once
> > we settle on how to do that bit shifting/clz().
> >
>
> [..]
> Here's the answer: on properly isolated perf test run (my
> old&legacy&predictiable
> 4s32c64t NUMA box, s_b=8GB, DB size 16GB, hugepages, no turboboost, proper
> warmup,
> no THP, cpupower D0, no physical I/O, ~22k pread64() calls/sec combined to
> VFS
> cache)
> and started on just using single NUMA: numactl --membind=0
> --cpunodebind=0
> measured using: pgbench -M prepared -c 4 -j 4 postgres -T 20 -P 1 -S
>
> master+track_io_timings=on, 60s warmup and then 3x runs
> tps = 44615.603668
> tps = 44556.191492
> tps = 44813.793981
> avg = 44662
>
> master+track_io_timings=on+patch, , 60s warmup and then 3x runs
> tps = 44441.879384
> tps = 44403.101737
> tps = 45036.747418
> avg = 44627
>
> so that's like 99.921% (so literally no overhead) and yields picture like:

I don't think that's a particularly useful assurance, unfortunately:

1) Using pgbench with an in-memory readonly workload is typically limited by
context switch overhead and per-statement overhead. After a short while you
have at most one IO per statement (the heap page), which obviously isn't
going to be affected by a small per-IO overhead.

2) The per-core memory bandwidth on that old machine, if it's the quite old
EDB machine I think it is, is so low, that you'd be bottlenecked by memory
bandwidth well before you're going to be bottlenecked by actual CPU stuff
(which the bucket computation is).

I think you'd have to test something like pg_prewarm(), with
io_combine_limit=1, on a modern *client* CPU (client CPUs typically have much
higher per-core memory bandwidth than the more scalable server CPUs).

Greetings,

Andres Freund