Horton

Re: What is a typical precision of gettimeofday()?

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Hannu Krosing <hannuk@google.com>
Cc: "Andrey M. Borodin" <x4mmm@yandex-team.ru>, Peter Eisentraut <peter@eisentraut.org>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-07-07T21:38:29Z
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

Hannu Krosing <hannuk@google.com> writes:
> Here is the latest patch with documentation only for the utility
> itself. Old general discussion moved to PostgreSQL Wiki with link to
> it in "See Also " section

Thanks for continuing to work on this!

> Also added a flag to select number of direct values to show

Hmm ... I agree with having a way to control the length of that output,
but I don't think that specifying a count is the most useful way to
do it.  Particularly with a default of only 10, it seems way too
likely to cut off important information.

What do you think of instead specifying the limit as the maximum
running-percentage to print, with a default of say 99.99%?  That
gives me results like

Observed timing durations up to 99.9900%:
      ns   % of total  running %      count
      15       4.5452     4.5452    8313178
      16      58.3785    62.9237  106773354
      17      33.6840    96.6078   61607584
      18       3.1151    99.7229    5697480
      19       0.2638    99.9867     482570
      20       0.0093    99.9960      17054

In the attached I also made it print the largest observed
duration, which seems like it might be useful information.

As previously threatened, I also added a test case to
improve the code coverage.

			regards, tom lane