Michael Banck <[email protected]> writes:
> This is the pg_test_timing output on my hurd-i386 VM with
> pg_test_timing from HEAD:
Ask and ye shall receive ... sorry for not reading the whole thread.
> I wonder what is going on here, was that a fluke or is that not related
> to the stats isolation test failure after all? Anybody else tried the
> updated pg_test_timing on Apple hardware and could possibly run the tt.c
> test case from Alexander?
Yeah, I see zero-ns outputs on a couple different Apple M-series
machines. This is the output on the M4 Mini that runs the sifaka
and indri BF animals:
$ pg_test_timing
Testing timing overhead for 3 seconds.
Average loop time including overhead: 17.22 ns
Histogram of timing durations:
<= ns % of total running % count
0 58.8235 58.8235 102495613
1 0.0000 58.8235 0
3 0.0000 58.8235 0
7 0.0000 58.8235 0
15 0.0000 58.8235 0
31 0.0000 58.8235 0
63 41.1229 99.9464 71653499
127 0.0502 99.9966 87421
255 0.0026 99.9992 4522
511 0.0000 99.9992 56
1023 0.0001 99.9993 117
2047 0.0001 99.9994 164
4095 0.0003 99.9997 558
8191 0.0003 100.0000 501
16383 0.0000 100.0000 50
32767 0.0000 100.0000 17
65535 0.0000 100.0000 0
131071 0.0000 100.0000 1
Observed timing durations up to 99.9900%:
ns % of total running % count
0 58.8235 58.8235 102495613
41 13.7077 72.5313 23884717
42 27.4151 99.9464 47768782
83 0.0277 99.9741 48304
84 0.0140 99.9881 24425
125 0.0084 99.9966 14692
...
107083 0.0000 100.0000 1
Those animals are not showing failures, so we can't blame
"clock didn't advance" as a problem in itself. However,
the thing that jumps out at me from your results is that
the clock resolution seems to be only 3 to 4 us on Hurd:
> Histogram of timing durations:
> <= ns % of total running % count
> 0 0,0510 0,0510 122
> 1 0,0000 0,0510 0
> 3 0,0000 0,0510 0
> 7 0,0000 0,0510 0
> 15 0,0000 0,0510 0
> 31 0,0000 0,0510 0
> 63 0,0000 0,0510 0
> 127 0,0000 0,0510 0
> 255 0,0000 0,0510 0
> 511 0,0000 0,0510 0
> 1023 0,0004 0,0514 1
> 2047 0,0000 0,0514 0
> 4095 98,9320 98,9834 236681
> 8191 0,8845 99,8679 2116
It seems plausible that the execution time of the stats
test's function-under-test is so short that it sometimes
doesn't register as more than zero on a machine with poor
clock resolution. It looks like that test only calls the
test function once or twice before checking that it's
accumulated some runtime, and the test function is nothing
more than
CREATE FUNCTION test_stat_func() RETURNS VOID LANGUAGE plpgsql AS $$BEGIN
END;$$;
I'd call this a bug in that test TBH. It'd be saner to
make the function do something like pg_sleep for 1ms.
regards, tom lane
