| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, Hannu Krosing <hannuk(at)google(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: What is a typical precision of gettimeofday()? |
| Date: | 2024-06-19 15:44:45 |
| Message-ID: | 9e7b21e7-4c63-4299-87f4-780a0699a7d8@eisentraut.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 18.06.24 07:47, Andrey M. Borodin wrote:
>
>
>> On 19 Mar 2024, at 13:28, Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>>
>> I feel that we don't actually have any information about this portability concern. Does anyone know what precision we can expect from gettimeofday()? Can we expect the full microsecond precision usually?
>
> At PGConf.dev Hannu Krossing draw attention to pg_test_timing module. I’ve tried this module(slightly modified to measure nanoseconds) on some systems, and everywhere I found ~100ns resolution (95% of ticks fall into 64ns and 128ns buckets).
AFAICT, pg_test_timing doesn't use gettimeofday(), so this doesn't
really address the original question.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2024-06-19 15:48:47 | Re: suspicious valgrind reports about radixtree/tidstore on arm64 |
| Previous Message | Peter Eisentraut | 2024-06-19 15:34:52 | Re: Better error message when --single is not the first arg to postgres executable |