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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hannu Krosing <hannuk(at)google(dot)com>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: What is a typical precision of gettimeofday()?
Date: 2024-07-02 16:55:53
Message-ID: 3110108.1719939353@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Hannu Krosing <hannuk(at)google(dot)com> writes:
>> This is my current patch which also adds running % and optionally uses
>> faster way to count leading zeros, though I did not see a change from
>> that.

> I've not read the patch yet, but I did create a CF entry [1]
> to get some CI cycles on this. The cfbot complains [2] about
> [ a couple of things ]

Here's a cleaned-up code patch addressing the cfbot complaints
and making the output logic a bit neater.

I think this is committable code-wise, but the documentation needs
work, if not indeed a complete rewrite. The examples are now
horribly out of date, and it seems that the "Clock Hardware and Timing
Accuracy" section is quite obsolete as well, since it suggests that
the best available accuracy is ~100ns.

TBH I'm inclined to rip most of the OS-specific and hardware-specific
information out of there, as it's not something we're likely to
maintain well even if we got it right for current reality.

regards, tom lane

Attachment Content-Type Size
v2-pg_test_timing-nanoseconds.patch text/x-diff 4.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2024-07-02 16:55:59 Re: Adding skip scan (including MDAM style range skip scan) to nbtree
Previous Message Noah Misch 2024-07-02 16:51:45 Re: Built-in CTYPE provider