On Fri, Nov 8, 2024 at 1:25 PM Sergey Prokhorenko <sergeyprokhore...@yahoo.com.au> wrote: > > 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.
Do you think method 3 is sufficient even with microsecond precision (i.e. storing only 10 bits microseconds in rand_a space)? Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
