Horton

Re: UUID v7

Sergey Prokhorenko <sergeyprokhorenko@yahoo.com.au>

View thread View on postgr.es
From: Sergey Prokhorenko <sergeyprokhorenko@yahoo.com.au>
To: Jelte Fennema-Nio <postgres@jeltef.nl>, "Andrey M. Borodin" <x4mmm@yandex-team.ru>, Peter Eisentraut <peter@eisentraut.org>
Cc: Aleksander Alekseev <aleksander@timescale.com>, pgsql-hackers mailing list <pgsql-hackers@postgresql.org>, Przemysław Sztoch <przemyslaw@sztoch.pl>, "David G. Johnston" <david.g.johnston@gmail.com>, Mat Arye <mat@timescaledb.com>, Matthias van de Meent <boekewurm+postgres@gmail.com>, Nikolay Samokhvalov <samokhvalov@gmail.com>, Junwang Zhao <zhjwpku@gmail.com>
Date: 2024-03-22T13:42:20Z
Lists: pgsql-hackers 
Why not use a single UUID generator for the database table in this case, similar to autoincrement?


Sergey Prokhorenko
sergeyprokhorenko@yahoo.com.au 

    On Friday, 22 March 2024 at 03:51:20 pm GMT+3, Peter Eisentraut <peter@eisentraut.org> wrote:  
 
 On 21.03.24 16:21, Jelte Fennema-Nio wrote:
> On Wed, 20 Mar 2024 at 19:08, Andrey M. Borodin <x4mmm@yandex-team.ru> wrote:
>> Timer-based bits contribute to global sortability. But the real timers we have are not even millisecond adjusted. We can hope for ~few ms variation in one datacenter or in presence of atomic clocks.
> 
> I think the main benefit of using microseconds would not be
> sortability between servers, but sortability between backends.

There is that, and there are also multiple backend workers for one session.

Commits

  1. Fix timestamp overflow in UUIDv7 implementation.

  2. Add UUID version 7 generation function.

  3. Add some UUID support functions