Hi,
On 2026-02-12 08:05:27 -0800, Lukas Fittl wrote:
> On master (88327092ff0), I'm getting 23.54 ns from pg_test_timing - vs
> with 0002 applied, this slows to 25.74 ns. I've tried to see if the
> "unlikely(..)" we added in pg_ticks_to_ns is the problem (since in the
> clock_gettime() case we'd always be running into that branch due to
> the size of the nanoseconds value), but no luck - I think the extra
> multiplication/division itself is the problem.
>
> Any ideas how we could do this differently?
The problem looks to be that you're going to take the slowpath when using
clock_gettime(), unless you booted within the last three days, because
pg_test_timing() is doing
INSTR_TIME_SET_CURRENT(temp);
cur = INSTR_TIME_GET_NANOSEC(temp);
Which will require reducing time-since-boot in nanoseconds (with
CLOCK_MONOTONIC) via pg_ticks_to_ns() overflow logic, as the way
max_ticks_no_overflow is set in 0001, it'll overflow after a few days of
runtime.
This can largely be addressed by keeping prev and cur in the instr_time
domain and only converting the difference to nanoseconds.
I wonder if pg_test_timing should have a small loop with a fixed count to
determine the timing without all the overhead the existing loop has...
Greetings,
Andres Freund
