From: | Sergey Prokhorenko <sergeyprokhorenko(at)yahoo(dot)com(dot)au> |
---|---|
To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru> |
Cc: | 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 21:25:26 |
Message-ID: | 852071238.331088.1731101126891@mail.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thursday 7 November 2024 at 11:34:31 am GMT+3, Andrey M. Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
> 12 bits does not differ much. We can have much longer counters. Before switching to Method 3 I used 18 bits counter. See version v24-0001-Implement-UUID-v7.patch> This version is more resilent to generating a lot of UUIDs on one backend while still not accumulating time shift.> Yet, UUIDs generated on parallel workers will loose some sortability.
> Personally, I think both methods are good. I’d even combine them both. But RFC seems to be not allowing this. BTW if we just continue to use nanoseconds patch, zero bits will act exactly as counters.
> Best regards, Andrey Borodin.------------------------------------------------------------------------
In fact, the RFC does allow combining methods 3 and 1:https://datatracker.ietf.org/doc/html/rfc9562#name-uuid-version-7 5.7. UUID Version 7
"Alternatively, implementations MAY fill the 74 bits, jointly, with a combination of the following subfields, in this order from the most significant bits to the least, to guarantee additional monotonicity within a millisecond:
1. An OPTIONAL sub-millisecond timestamp fraction (12 bits at maximum) as per Section 6.2 (Method 3).2. An OPTIONAL carefully seeded counter as per Section 6.2 (Method 1 or 2).3. Random data for each new UUIDv7 generated for any remaining space."
This clearly refers to a "combination of the following subfields". COMBINATION!!!
However, with the current performance of computers, method 3 is quite sufficient without the addition of method 1.
Sergey Prokhorenko sergeyprokhorenko(at)yahoo(dot)com(dot)au
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-11-08 21:42:14 | Draft back-branch release notes are up |
Previous Message | Nathan Bossart | 2024-11-08 21:20:00 | Re: Fix port/pg_iovec.h building extensions on x86_64-darwin |