On 4 Oct 2026, Tom Lane wrote:
> it's bandying around not two but three(!) different clock precisions,
The interval argument was intended to spread concurrent insert streams
over different index hot spots, keeping locality within each stream.
It shifts the generator's clock rather than taking an application
timestamp to encode. We discussed that distinction at some length
during development [0].
The precisions are deliberate: milliseconds for the UUID field,
microseconds for interval arithmetic, and finer clock precision for
the sub-millisecond bits. RFC 9562's Method 3 uses that extra precision
to reduce collisions [1], so we preserve the nanosecond remainder
across the interval calculation.
As for the original report, storing an arbitrary application timestamp
in a UUID is not the intended use. In our interpretation of the RFC,
these bits serve uniqueness and ordering, not timestamp storage. The
function deliberately uses its own clock, so
uuidv7(target - clock_timestamp()) does not promise to preserve the
exact microseconds of target.
Thank you!
Best regards, Andrey Borodin.
[0] https://www.postgresql.org/message-id/1012137874.340418.1721776188406@mail.yahoo.com
[1] https://www.rfc-editor.org/rfc/rfc9562.html#section-6.2
