Re: UUID v7

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

In response to

  • Re: UUID v7 at 2024-11-07 08:34:14 from Andrey M. Borodin

Responses

  • Re: UUID v7 at 2024-11-08 21:59:30 from Masahiko Sawada

Browse pgsql-hackers by date

  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