Re: What is a typical precision of gettimeofday()? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: What is a typical precision of gettimeofday()?
Date
Msg-id 919140.1752013063@sss.pgh.pa.us
Whole thread Raw
In response to What is a typical precision of gettimeofday()?  (Peter Eisentraut <peter@eisentraut.org>)
Responses Re: What is a typical precision of gettimeofday()?
List pgsql-hackers
Hannu Krosing <hannuk@google.com> writes:
> On Tue, Jul 8, 2025 at 10:01 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> No, I think what's happening there is that we get to NUM_DIRECT before
>> reaching the 99.99% mark.

> Makes sense.
> Should we change the header to something like
> "Showing values covering up to 99.9900% of total observed timing
> durations below 1 us. "

I think that'd just confuse people more not less.

> And maybe 10,001 would be a better value for collection, especially on
> older machines which could in fact have some wose timer resolution ?

I don't have any objection to boosting NUM_DIRECT to 10K or so.
It will cause the stats display loop to take microscopically longer,
but that shouldn't matter, even on slow machines.

One other thing that bothers me as I look at the output is

    Per loop time including overhead: 731.26 ns

That's stated in a way that makes it sound like that is a
very solid number, when in fact it's just the average.
We see from these test cases that there are frequently
a few outliers that are far from the average.  I'm tempted
to rephrase as

    Average loop time including overhead: 731.26 ns

or some variant of that.  Thoughts?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: Non-text mode for pg_dumpall
Next
From: Michael Paquier
Date:
Subject: Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem)