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 →
  1. Force LC_NUMERIC to C while running TAP tests.

  2. Minor tweaks for pg_test_timing.

  3. Change pg_test_timing to measure in nanoseconds not microseconds.

Attachments

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