> On 19 Mar 2024, at 13:55, Peter Eisentraut <pe...@eisentraut.org> wrote: > > On 16.03.24 18:43, Andrey M. Borodin wrote: >>> On 15 Mar 2024, at 14:47, Aleksander Alekseev <aleksan...@timescale.com> >>> wrote: >>> >>> +1 to the idea. I doubt that anyone will miss it. >> PFA v22. >> Changes: >> 1. Squashed all editorialisation by Jelte >> 2. Fixed my erroneous comments on using Method 2 (we are using method 1 >> instead) >> 3. Remove all traces of uuid_extract_variant() > > I have committed a subset of this for now, namely the additions of > uuid_extract_timestamp() and uuid_extract_version(). These seemed mature and > agreed upon. You can rebase the rest of your patch on top of that.
Great! Thank you! PFA v23 with rebase on HEAD. > I have started a separate discussion to learn about the precision we can > expect from gettimeofday(). Even in presence of real microsecond-enabled and portable timer using microseconds does not seem to me an optimal way of utilising UUID bits. 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. Time-based bits contribute to global uniqueness, but certainly they are not that effective as counter bits. Time-based bits do not provide local sortability guarantees: some UUIDs might get same microseconds or be affected by leap backwards. I think that microseconds are good only for hardware-specific solutions, not for something that runs on variety of platforms, OSes, devices. Best regards, Andrey Borodin.
v23-0001-Implement-UUID-v7.patch
Description: Binary data
