Re: pg_stat_io_histogram

On Fri, Jan 30, 2026 at 2:43 PM Jakub Wartak
<jakub.wartak@enterprisedb.com> wrote:
[..]
> I'm attaching v3 which has now default switched to __builtin_clzl() which
> works ok for uint64 (not sure if I need to care about __builtin_clzll
> on Windows?).

Here comes the v4:

1. Rebased just in case.
2. Earlier appears to the uncomplete patch without local changes (comment
   mentioned use of __builtin_clzl,  but actually code called
   __builtin_clz -- 32-bit one not long one), fixed that with the new
   version.
3. I've added discovery of __builtin_clzl into autoconf/meson as it was
   missing (although comment there says "We assume that we needn't test
   all widths of these explicitly:", but isn't it safer we test explicitly
   what we use?
4. And then I've spotted that pg_leftmost_one_pos64() in pg_binutils.h uses on
   master the __builtin_clzl already, so I've tweaked it to use check
   HAVE__BUILTIN_CLZL (not CLZ) too once we have that now.

Open questions:
0. Should I pursue more benchmarking or the above results are enough?
1. Should I add per-PID backend stats too or skip that to avoid causing
   potential further overhead? (probably yet another memcpy...)
2. Shouldn't we fix that mdsyncfiletag() mentioned earlier we seem to have
   pgstat_count_io_op_time() *after* potential FileClose() (as per my
   earlier question)

-J.