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:50:13Z
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
Hannu Krosing <hannuk@google.com> writes: > Also, reading directly in ticks on M1 gave "loop time including > overhead: 2.13 ns" (attached code works on Clang, not sure about GCC) I don't think we should mess with that, given the portability problems you mentioned upthread. > I'll also take a look at the docs and try to propose something OK. > Do we also need tests for this one ? Yeah, it was annoying me that we are eating the overhead of a TAP test for pg_test_timing and yet it covers barely a third of the code [1]. We obviously can't expect any specific numbers out of a test, but I was contemplating running "pg_test_timing -d 1" and just checking for (a) zero exit code and (b) the expected header lines in the output. regards, tom lane [1] https://coverage.postgresql.org/src/bin/pg_test_timing/pg_test_timing.c.gcov.html