We currently do something similar with OIDs where we just keep
generating them and then testing for conflicts.
I don't think this is the best way to do it but it mostly works when
you can actually test for uniqueness, like for example in TOAST or
system tables.
Not sure this works even reasonably well for UUIDv7.
--
Hannu
On Wed, Jul 3, 2024 at 12:38 PM Andrey M. Borodin <x4mmm@yandex-team.ru> wrote:
>
>
>
> > On 3 Jul 2024, at 13:48, Aleksander Alekseev <aleksander@timescale.com> wrote:
> >
> > Hi,
> >
> >> That’s a very interesting result, from the UUID POV!
> >> If time is almost always advancing, using time readings instead of a counter is very reasonable: we have
interprocessmonotonicity almost for free.
> >> Though time is advancing in a very small steps… RFC assumes that we use microseconds, I’m not sure it’s ok to use
10more bits for nanoseconds…
> >
> > A counter is mandatory since someone can for instance change the
> > system's time while the process is generating UUIDs. You can't
> > generally assume that local time of the system is monotonic.
>
> AFAIR according to RFC when time jumps backwards, we just use time microseconds as a counter. Until time starts to
advanceagain.
>
>
> Best regards, Andrey Borodin.
