On Wed, 20 Mar 2024 at 07:35, Peter Eisentraut wrote:
> If we want to be robust without any guarantees from gettimeofday(), then
> arguably gettimeofday() is not the right underlying function to use for
> UUIDv7.
There's also clock_gettime which exposes its resolution using clock_getres
On 19.03.24 10:38, Aleksander Alekseev wrote:
Considering the number of environments PostgreSQL can run in (OS +
hardware + virtualization technologies) and the fact that
hardware/software changes I doubt that it's realistic to expect any
particular guarantees from gettimeofday() in the general
Hi,
cc: Andrey
> Over in the thread discussing the addition of UUIDv7 support [0], there
> is some uncertainty about what timestamp precision one can expect from
> gettimeofday().
>
> UUIDv7 uses milliseconds since Unix epoch, but can optionally use up to
> 12 additional bits of timestamp
Over in the thread discussing the addition of UUIDv7 support [0], there
is some uncertainty about what timestamp precision one can expect from
gettimeofday().
UUIDv7 uses milliseconds since Unix epoch, but can optionally use up to
12 additional bits of timestamp precision (see [1]), but it
