On Thursday 7 November 2024 at 11:34:31 am GMT+3, Andrey M. Borodin <x4...@yandex-team.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 sergeyprokhore...@yahoo.com.au
