| From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
|---|---|
| To: | Sergey Prokhorenko <sergeyprokhorenko(at)yahoo(dot)com(dot)au> |
| Cc: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Daniel Verite <daniel(at)manitou-mail(dot)org>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Przemysław Sztoch <przemyslaw(at)sztoch(dot)pl>, Michael Paquier <michael(at)paquier(dot)xyz>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, Pgsql-Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org>, "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: | 2025-02-04 22:06:22 |
| Message-ID: | CAD21AoDxp7px0p-z+yszX==sr1NTZsxUa8rtm2jqinPp+0CpMQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Feb 2, 2025 at 11:41 AM Sergey Prokhorenko
<sergeyprokhorenko(at)yahoo(dot)com(dot)au> wrote:
>
> Dear colleagues,
>
> I would like to present for discussion my attached new draft documentation on UUID functions (Section 9.14. UUID Functions), which replaces the previously proposed draft at https://www.postgresql.org/docs/devel/functions-uuid.html. I have preserved and significantly supplemented the text that was there.
>
> I have the following goals:
>
> 1. State that from now on, the function uuidv7(), rather than autoincrement, is the default choice for generating primary keys
>
> 2. Describe the advantages of uuidv7() over autoincrement and uuidv4()
>
> 3. Refute the often-cited imaginary disadvantages of UUIDv7 compared to autoincrement, such as:
>
> - Lower performance (see the refutation in the article "UUID Benchmark War" https://ardentperf.com/2024/02/03/uuid-benchmark-war/)
>
> - Disclosure of date and time of record creation in the table (in reality, the timestamp offset parameter distorts this information)
>
> 4. Confirm the fault tolerance of the uuidv7() function in all possible critical situations, namely:
>
> - System clock failure
>
> - Receiving an invalid value of the offset argument, which would result in a timestamp overflow or a negative timestamp
>
Thank you for the proposal. Could you share the proposed document as a
.diff or .patch file? That would be easier to review the updates.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Nasby | 2025-02-04 22:28:47 | Re: should we have a fast-path planning for OLTP starjoins? |
| Previous Message | Masahiko Sawada | 2025-02-04 22:02:55 | Re: UUID v7 |