←back to thread

230 points craigkerstiens | 1 comments | | HN request time: 0.202s | source
Show context
fngjdflmdflg ◴[] No.42576248[source]
>The Postgres patch solves the problem by repurposing 12 bits of the UUID’s random component to increase the precision of the timestamp down to nanosecond granularity [...]

>It makes a repeated UUID between processes more likely, but there’s still 62 bits of randomness left to make use of, so collisions remain vastly unlikely.

Does it? Even though the number of random bits has decreased, the time interval to create such a duplicate has also decreased, namely to an interval of one nanosecond.

replies(3): >>42576319 #>>42576330 #>>42577456 #
londons_explore ◴[] No.42576330[source]
I could imagine that certain nanoseconds might be vastly more likely than other nanoseconds.

For example, imagine you have a router that sends network packets out at the start of each microsecond, synced to wall time.

Or the OS scheduler always wakes processes up on a millisecond timer tick or some polling loop.

Now, when those packets are received by a postgres server and processed, the time to do that is probably fairly consistent - meaning that X nanoseconds past the microsecond you probably get most records being created.

replies(1): >>42576494 #
UltraSane ◴[] No.42576494[source]
But only one nanosecond slower or faster and you get another set of 4.611 billion billion random IDs. I think random variations in buffer depths and CPU speeds will easily introduce hundreds of nanoseconds of timing variations. syncing any two things to less than 1 nanosecond is incredibly hard and doesn't happen by accident.
replies(3): >>42576585 #>>42577223 #>>42593338 #
mlyle ◴[] No.42577223[source]
We're not talking about nanoseconds of real time; we're talking about nanoseconds as measured by the CPU doing the processing. Nanoseconds are not likely to be a uniform variate.
replies(1): >>42577302 #
UltraSane ◴[] No.42577302[source]
Yes and they are also not likely to be so non-uniform that more than 6.411 billion billion events all happen in one nanosecond.
replies(1): >>42577523 #
mlyle ◴[] No.42577523[source]
Note it's not that number, but roughly the square root of that number, that matters.

And they might be quite non-uniform. If the scheduler tick and the nanosecond clock are synchronous, you could end up with a few thousand popular values instead of a billion.

It's not a real concern today, and probably won't be a real concern in 10 years, but it's not so far removed from possibility that no one has to think about it.

replies(1): >>42577649 #
1. UltraSane ◴[] No.42577649[source]
Good point about the square root of the random part. I guess that is why the 63 bit Snowflake ID uses a sequential counter.