Re: What is a typical precision of gettimeofday()?
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Hannu Krosing <hannuk@google.com>
Cc: Peter Eisentraut <peter@eisentraut.org>,
"Andrey M. Borodin" <x4mmm@yandex-team.ru>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-07-02T17:20:14Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Force LC_NUMERIC to C while running TAP tests.
- f25792c541e5 19 (unreleased) landed
-
Minor tweaks for pg_test_timing.
- 9dcc7641444f 19 (unreleased) landed
-
Change pg_test_timing to measure in nanoseconds not microseconds.
- 0b096e379e6f 19 (unreleased) landed
Attachments
- pg_test_timing.results.txt (text/plain)
BTW, getting back to the original point of the thread: I duplicated
Hannu's result showing that on Apple M1 the clock tick seems to be
about 40ns. But look at what I got with the v2 patch on my main
workstation (full output attached):
$ ./pg_test_timing
...
Per loop time including overhead: 16.60 ns
...
Timing durations less than 128 ns:
ns % of total running % count
15 3.2738 3.2738 5914914
16 49.0772 52.3510 88668783
17 36.4662 88.8172 65884173
18 9.5639 98.3810 17279249
19 1.5746 99.9556 2844873
20 0.0416 99.9972 75125
21 0.0004 99.9976 757
...
It sure looks like this is exact-to-the-nanosecond results,
since the modal values match the overall per-loop timing,
and there are no zero measurements.
This is a Dell tower from 2021, running RHEL8 on an Intel Xeon W-2245.
Not exactly top-of-the-line stuff.
regards, tom lane