public inbox for [email protected]
help / color / mirror / Atom feedFrom: Sergey Prokhorenko <[email protected]>
To: Andrey M. Borodin <[email protected]>
Cc: pgsql-hackers mailing list <[email protected]>
Cc: Aleksander Alekseev <[email protected]>
Cc: Przemysław Sztoch <[email protected]>
Cc: Nikolay Samokhvalov <[email protected]>
Cc: David G. Johnston <[email protected]>
Cc: Jelte Fennema-Nio <[email protected]>
Cc: Nick Babadzhanian <[email protected]>
Cc: Mat Arye <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Daniel Gustafsson <[email protected]>
Cc: Matthias van de Meent <[email protected]>
Cc: Nikolay Samokhvalov <[email protected]>
Cc: Kyzer Davis (kydavis) <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: [email protected] <[email protected]>
Cc: Kirk Wolak <[email protected]>
Subject: Re: UUID v7
Date: Tue, 30 Jan 2024 00:27:21 +0000 (UTC)
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CAAhFRxitJv=yoGnXUgeLB_O+M7J2BJAmb5jqAT9gZ3bij3uLDA@mail.gmail.com>
<CAGECzQQ=38bVUR=LZ6vmBCEjaDfOOoQa+ygFJ1mCG_H2jsC90Q@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAJ7c6TPcYQHWYa97MiETT6O8=3Yq=r0CMtyu0y3DEYmOcmnmPA@mail.gmail.com>
<[email protected]>
<CAJ7c6TPZZg8uM+2=Hj_s-gcvYCfYo=8ABZPTBvvh=mkCdRot9Q@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAKFQuwai1N+Tm-P91zqnJEmT11kD7RqJLJrrhWFSxS1pRSR47w@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAM527d__3qQxvpUC_5tWW5TeodE=bivYT3eNDpjrVAk3-uU0TA@mail.gmail.com>
<[email protected]>
<CAM527d8QbYa9CfsUezn_owUP8M0JWGYiosMEOkQqD6=PsncEnA@mail.gmail.com>
<[email protected]>
<f0c8f561-9f68-0634-b815-33a629 [email protected]>
<CAJ7c6TPX5xJSr17806LOGcvuM5kk3jEtRoHSmZkLuG52zYoZuA@mail.gmail.com>
<[email protected]>
<[email protected]>
Andrey,
I understand and agree with your goals. But instead of dangerous universal functions, it is better to develop safe highly specialized functions that implement only these goals.
There should not be a function uuidv7(T) from an arbitrary timestamp, but there should be a special function that implements your algorithm: uuidv8(now() + '1 century' * random(0,10)).
I replaced 1 day with 1 century because the spread of 1 day is too small. Over time, records will be inserted between existing records, which is undesirable.
Similarly, if we need to calculate the partition id, then we do not need to use the uuid_extract_time() function to provide the extracted timestamp, the accuracy of which cannot be guaranteed. Instead, we need to give exactly the partition id, calculated using the uuidv7 timestamp. For example, partitions may have approximately a month interval between each other.
As for the documentation, it must be indicated that the UUIDv7 structure is not timestamp + random, but timestamp + randomly seeded counter + random, like in all advanced implementations.
Sergey Prokhorenko
[email protected]
______________________________________________________________
On Monday, 29 January 2024 at 09:32:54 pm GMT+3, Andrey M. Borodin <[email protected]> wrote:
> On 25 Jan 2024, at 22:04, Sergey Prokhorenko <[email protected]> wrote:
>
> Aleksander,
>
> In this case the documentation must state that the functions uuid_extract_time() and uuidv7(T) are against the RFC requirements, and that developers may use these functions with caution at their own risk, and these functions are not recommended for production environment.
Refining documentation is good. However, saying that these functions are not recommended for production must be based on some real threats.
>
> The function uuidv7(T) is not better than uuid_extract_time(). Careless developers may well pass any business date into this function: document date, registration date, payment date, reporting date, start date of the current month, data download date, and even a constant. This would be a profanation of UUIDv7 with very negative consequences.
Even if the developer pass constant time to uuidv7(T) they will get what they asked for - unique identifier. Moreover - it still will be keeping locality. There will be no negative consequences at all.
On the contrary, experienced developer can leverage parameter when data locality should be reduced. If you have serveral streams of data, you might want to introduce some shift in reduce contention.
For example, you can generate uuidv7(now() + '1 day' * random(0,10)). This will split 1 contention point to 10 and increase ingestion performance 10x-fold.
> On 29 Jan 2024, at 18:58, Junwang Zhao <[email protected]> wrote:
>
> If other timestamp sources or
> a custom timestamp epoch are required, UUIDv8 MUST be used.
Well, yeah. RFC says this... in 4 capital letters :) I believe it's kind of a big deficiency that k-way sortable identifiers are not implementable on top of UUIDv7. Well, let's go without this function. UUIDv7 is still an improvement over previous versions.
Jelte, your documentation corrections looks good to me, I'll include them in next version.
Thanks!
Best regards, Andrey Borodin.
view thread (69+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: UUID v7
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox