On Tue, Jul 8, 2025 at 8:07 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > BTW, returning to the original topic of this thread: > > The new exact-delays table from pg_test_timing is really quite > informative.
Maybe we should collect some of it in the PostgreSQL Wiki for easy reference ? I had some interesting results with some RISC-V SBC which were similar to ARM but seemed to indicate that the chosen "CPU CLOCK" used by the rtdsc-equivalent instruction was counting in exact multiples of a nanosecond And "the rtdsc-equivalent instruction" on both ARM and RISC-V is reading a special register which exposes the faked "clock counter". > For example, on my M4 Macbook: > > Observed timing durations up to 99.9900%: > ns % of total running % count > 0 62.2124 62.2124 118127987 > 41 12.5826 74.7951 23891661 > 42 25.1653 99.9604 47783489 > 83 0.0194 99.9797 36744 > 84 0.0096 99.9893 18193 > 125 0.0020 99.9913 3784 > ... > 31042 0.0000 100.0000 1 > > The fact that the clock tick is about 40ns is extremely > obvious in this presentation. > > Even more interesting is what I got from an ancient PPC Macbook > (mamba's host, running NetBSD): > > Testing timing overhead for 3 seconds. > Per loop time including overhead: 731.26 ns > ... > Observed timing durations up to 99.9900%: > ns % of total running % count > 705 39.9162 39.9162 1637570 > 706 17.6040 57.5203 722208 > 759 18.6797 76.2000 766337 > 760 23.7851 99.9851 975787 > 813 0.0002 99.9853 9 > 814 0.0004 99.9857 17 > 868 0.0001 99.9858 4 > 922 0.0001 99.9859 3 Do we have a fencepost error in the limit code so that it stops before printing out the 99.9900% limit row ? The docs in your latest patch indicated that it prints out the row >= 99.9900% --- Hannu
