Currently pg_test_timing utility measures its timing overhead in
microseconds, giving results like this
~$ /usr/lib/postgresql/15/bin/pg_test_timing
Testing timing overhead for 3 seconds.
Per loop time including overhead: 18.97 ns
Histogram of timing durations:
< us % of total count
1 98.11132 155154419
2 1.88756 2985010
4 0.00040 630
8 0.00012 184
16 0.00058 919
32 0.00003 40
64 0.00000 6
I got curious and wanted to see how the 98.1% timings are distributed
(raw uncleaned patch attached)
And this is what I got when I increased the measuring resolution to nanoseconds
hannuk@hannuk1:~/work/postgres15_uni_dist_on/src/bin/pg_test_timing$
./pg_test_timing
Testing timing overhead for 3 seconds.
Per loop time including overhead: 17.34 ns, min: 15, same: 0
Histogram of timing durations:
< ns % of total count
1 0.00000 0
2 0.00000 0
4 0.00000 0
8 0.00000 0
16 1.14387 1979085
32 98.47924 170385392
64 0.21666 374859
128 0.15654 270843
256 0.00297 5139
512 0.00016 272
1024 0.00004 73
2048 0.00018 306
4096 0.00022 375
8192 0.00006 99
16384 0.00005 80
32768 0.00001 20
65536 0.00000 6
131072 0.00000 2
As most of the samples seems to be in ranges 8..15 and 16..32
nanoseconds the current way of measuring at microsecond resolution is
clearly inadequate.
The attached patch is not meant to be applied as-is but is rather
there as a helper to easily verify the above numbers.
QUESTIONS
1. Do you think it is ok to just change pg_test_timing to return the
result in nanoseconds or should there be a flag that asks for
nanosecond resolution ?
2. Should the output be changed to give ranges instead of `<ns`
numbers for better clarity, and leave out the "too small numbers" from
the beginning as well ?
So the first few lines would look like
8 .. 15 ....
16 .. 32 .....
....
---
Best Regards,
Hannu
