Re: UUID v7
Masahiko Sawada <sawada.mshk@gmail.com>
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: "Andrey M. Borodin" <x4mmm@yandex-team.ru>
Cc: Sergey Prokhorenko <sergeyprokhorenko@yahoo.com.au>, Jelte Fennema-Nio <postgres@jeltef.nl>, Michael Paquier <michael@paquier.xyz>, Aleksander Alekseev <aleksander@timescale.com>, pgsql-hackers mailing list <pgsql-hackers@postgresql.org>, Peter Eisentraut <peter@eisentraut.org>, Przemysław Sztoch <przemyslaw@sztoch.pl>, "David G. Johnston" <david.g.johnston@gmail.com>, Mat Arye <mat@timescaledb.com>, Matthias van de Meent <boekewurm+postgres@gmail.com>, Nikolay Samokhvalov <samokhvalov@gmail.com>, Junwang Zhao <zhjwpku@gmail.com>, Stepan Neretin <sncfmgg@gmail.com>
Date: 2024-11-08T22:58:55Z
Lists: pgsql-hackers
On Thu, Nov 7, 2024 at 12:34 AM Andrey M. Borodin <x4mmm@yandex-team.ru> wrote: > > > > > On 7 Nov 2024, at 12:42, Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > > On Wed, Nov 6, 2024 at 10:14 AM Andrey M. Borodin <x4mmm@yandex-team.ru> wrote: > >> > >> > >> > >>> On 5 Nov 2024, at 23:56, Andrey M. Borodin <x4mmm@yandex-team.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
Commits
-
Fix timestamp overflow in UUIDv7 implementation.
- a5419bc72e22 18.0 landed
-
Add UUID version 7 generation function.
- 78c5e141e9c1 18.0 landed
-
Add some UUID support functions
- 794f10f6b920 17.0 landed