Horton

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

Hannu Krosing <hannuk@google.com>

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

We currently do something similar with OIDs where we just keep
generating them and then testing for conflicts.

I don't think this is the best way to do it but it mostly works when
you can actually test for uniqueness, like for example in TOAST or
system tables.

Not sure this works even reasonably well for UUIDv7.

--
Hannu

On Wed, Jul 3, 2024 at 12:38 PM Andrey M. Borodin <x4mmm@yandex-team.ru> wrote:
>
>
>
> > On 3 Jul 2024, at 13:48, Aleksander Alekseev <aleksander@timescale.com> wrote:
> >
> > Hi,
> >
> >> That’s a very interesting result, from the UUID POV!
> >> If time is almost always advancing, using time readings instead of a counter is very reasonable: we have interprocess monotonicity almost for free.
> >> Though time is advancing in a very small steps… RFC assumes that we use microseconds, I’m not sure it’s ok to use 10 more bits for nanoseconds…
> >
> > A counter is mandatory since someone can for instance change the
> > system's time while the process is generating UUIDs. You can't
> > generally assume that local time of the system is monotonic.
>
> AFAIR according to RFC when time jumps backwards, we just use time microseconds as a counter. Until time starts to advance again.
>
>
> Best regards, Andrey Borodin.