Re: UUID v7 - Mailing list pgsql-hackers

From Sergey Prokhorenko
Subject Re: UUID v7
Date
Msg-id 1165679715.493882.1731172024740@mail.yahoo.com
Whole thread Raw
In response to Re: UUID v7  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: UUID v7
List pgsql-hackers
On Saturday 9 November 2024 at 01:00:15 am GMT+3, Masahiko Sawada <sawada.mshk@gmail.com> wrote:

> the microsecond part is working also as a counter in a sense. IT seems fine to me but I'm slightly concerned that there is no guidance of such implementation in RFC 9562.

In fact, there is guidance of similar implementation in RFC 9562:
https://datatracker.ietf.org/doc/html/rfc9562#name-monotonicity-and-counters
"Counter Rollover Handling:"
"Alternatively, implementations MAY increment the timestamp ahead of the actual time and reinitialize the counter."



> Do you think method 3 is sufficient even with microsecond precision (i.e. storing only 10 bits microseconds in rand_a space)?

The maximum write performance in PostgreSQL is approximately 500 rows per millisecond, but under normal conditions 50 rows per millisecond. This corresponds to a precision of 2 microseconds and 20 microseconds respectively.

Andrey Borodin's implementation of method 3 provides a precision of approximately 0.25 microseconds.

You offer a precision of approximately 0.98 microseconds. This is about twice as good as what is needed for 500 rows per millisecond write performance. But in the near future, this may not be enough for the highest-performance systems.


Sergey Prokhorenko
sergeyprokhorenko@yahoo.com.au

pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: New GUC autovacuum_max_threshold ?
Next
From: Rishu Bagga
Date:
Subject: Re: Proposal to add page headers to SLRU pages