Re: UUID v7

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>
Cc: Sergey Prokhorenko <sergeyprokhorenko(at)yahoo(dot)com(dot)au>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Michael Paquier <michael(at)paquier(dot)xyz>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, pgsql-hackers mailing list <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Przemysław Sztoch <przemyslaw(at)sztoch(dot)pl>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Mat Arye <mat(at)timescaledb(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>, Junwang Zhao <zhjwpku(at)gmail(dot)com>, Stepan Neretin <sncfmgg(at)gmail(dot)com>
Subject: Re: UUID v7
Date: 2024-11-08 22:58:55
Message-ID: CAD21AoBqkGNZyjeannKetLe5Oot9HEWmKzCYY08+uOJN=Uebww@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 7, 2024 at 12:34 AM Andrey M. Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
>
>
>
> > On 7 Nov 2024, at 12:42, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> >
> > On Wed, Nov 6, 2024 at 10:14 AM Andrey M. Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
> >>
> >>
> >>
> >>> On 5 Nov 2024, at 23:56, Andrey M. Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
> >>>
> >>> <v30-0001-Implement-UUID-v7.patch>
> >>
> >> Some more thoughts on this patch version:
> >>
> >> 0. Comment mentioning nanoseconds, while we do not need to carry anything
> >> /* Convert TimestampTz back and carry nanoseconds. */
> >>
> >> 1. There's unnecessary &3 in
> >> uuid->data[7] = uuid->data[7] | ((uuid->data[8] >> 6) & 3);
> >>
> >> 2. Currently we store 0..999 microseconds in 10 bits, so values 1000..1023 are unused. We could use them for overflow. That would slightly increase non-overflowing capacity when generating more than million UUIDs per second on one backend. However, given current performance of our CSPRNG I do not think this feature worth code complexity.
> >>
> >
> > While using only 10 bits microseconds makes the implementation simple,
> > I'm not sure if 10 bits is enough to generate UUIDs at microsecond
> > granularity without losing monotonicity. Since 10-bit microseconds are
> > used as is in rand_a space, 1000 UUIDs can be generated per
> > millisecond without losing monotonicity.
>
> We won’t loose monotonicity on one backend. We will just accumulate time shift.
> See
> + us = tv.tv_sec * SECS_PER_DAY * USECS_PER_SEC + tv.tv_usec;
> + if (previous_us >= us)
> + us = previous_us + 1;

IIUC the microsecond part is working also as a counter in a sense. It
seems fine to me but I'm slightly concerned that there is no guidance
of such implementation in RFC 9562.

> BTW if we just continue to use nanoseconds patch, zero bits will act exactly as counters.

Yes, but we will lose some randomness on macOS as the nanosecond part
is 0 in most cases.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

In response to

  • Re: UUID v7 at 2024-11-07 08:34:14 from Andrey M. Borodin

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2024-11-08 23:00:35 Re: define pg_structiszero(addr, s, r)
Previous Message Nathan Bossart 2024-11-08 22:36:18 Re: Fix port/pg_iovec.h building extensions on x86_64-darwin