On Fri, Nov 8, 2024 at 1:25 PM Sergey Prokhorenko
<sergeyprokhorenko@yahoo.com.au> wrote:
>
> On Thursday 7 November 2024 at 11:34:31 am GMT+3, Andrey M. Borodin <x4mmm@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
ifwe 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
orderfrom 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
