On Thu, Mar 27, 2025 at 10:31 PM Masahiko Sawada wrote:
>
> On Wed, Mar 26, 2025 at 12:32 PM Andrei Borodin wrote:
> >
> >
> >
> > 26.03.2025, 21:06, "Masahiko Sawada" :
> >
> > Agreed. I've done this in the attached patch.
> >
> > Great! The patch looks good to me.
>
> Thank you for reviewing it
On Wed, Mar 26, 2025 at 12:32 PM Andrei Borodin wrote:
>
>
>
> 26.03.2025, 21:06, "Masahiko Sawada" :
>
> Agreed. I've done this in the attached patch.
>
> Great! The patch looks good to me.
Thank you for reviewing it. I'm going to push the fix tomorrow,
barring further comments.
Regards,
--
M
26.03.2025, 21:06, "Masahiko Sawada" :Agreed. I've done this in the attached patch.Great! The patch looks good to me.Best regards, Andrey Borodin.
On Wed, Mar 26, 2025 at 6:00 AM Andrey Borodin wrote:
>
>
>
> > On 26 Mar 2025, at 08:32, Masahiko Sawada wrote:
> >
> > Please review it.
>
> The patch looks good to me except one nit.
> +WITH uuidts AS (
> + SELECT y, ts as ts, lag(ts) OVER (ORDER BY y) AS prev_ts
> + FROM (SELECT y, uu
> On 26 Mar 2025, at 08:32, Masahiko Sawada wrote:
>
> Please review it.
The patch looks good to me except one nit.
+WITH uuidts AS (
+ SELECT y, ts as ts, lag(ts) OVER (ORDER BY y) AS prev_ts
+ FROM (SELECT y, uuid_extract_timestamp(uuidv7((y || ' years')::interval))
AS ts FROM gene
On Sun, Feb 9, 2025 at 9:07 AM Andrey Borodin wrote:
>
> I've took into account note from Sergey that "offset" is better name for
> uuidv7() argument than "shift".
>
> > On 5 Feb 2025, at 03:02, Masahiko Sawada wrote:
> >
> >>
> >> I was thinking about incorporating test like this.
> >>
> W
Sergey Prokhorenko sergeyprokhore...@yahoo.com.au
On Monday 17 February 2025 at 04:21:31 am GMT+3, Andrew Alsup
wrote:
Sergey,
I took a look at your patch for chapter 9.14 "UUID Functions" docs page. You've
added some really good content here. I think section 9.14.4. "Deciding Wheth
On Monday, February 17, 2025, Sergey Prokhorenko <
sergeyprokhore...@yahoo.com.au> wrote:
> This means exactly the opposite of what you wrote. There is a big
> difference between UUID versions and data types. The properties of
> identifiers strongly depend on the implementation of generating funct
On Mon, Feb 17, 2025 at 12:57 PM Sergey Prokhorenko <
sergeyprokhore...@yahoo.com.au> wrote:
>
>
> Sergey Prokhorenko sergeyprokhore...@yahoo.com.au
>
>
> On Monday 17 February 2025 at 04:21:31 am GMT+3, Andrew Alsup <
> bluesbrea...@gmail.com> wrote:
>
>
> Sergey,
>
> I took a look at your patch
be helpful and thus the thread itself seems to be torn
between fixing stuff in UUID v7 and, separately, making a documentation
enhancement. I don't see a commitfest entry yet - so how about just
starting two new, well-named, threads, with a summary and current patch
proposal for each topic? Thou
Sergey,
I took a look at your patch for chapter 9.14 "UUID Functions" docs page.
You've added some really good content here. I think section 9.14.4.
"Deciding Whether and Which UUID to Use" would be better suited for Chapter
8: "Data Types" -- specifically, 8.12. "UUID Type", since the content see
On Wednesday 5 February 2025 at 01:07:02 am GMT+3, Masahiko Sawada
wrote:
On Sun, Feb 2, 2025 at 11:41 AM Sergey Prokhorenko
wrote:
>
> Dear colleagues,
>
> I would like to present for discussion my attached new draft documentation on
> UUID functions (Section 9.14. UUID Functions), which r
I've took into account note from Sergey that "offset" is better name for
uuidv7() argument than "shift".
> On 5 Feb 2025, at 03:02, Masahiko Sawada wrote:
>
>>
>> I was thinking about incorporating test like this.
>>
With this patch we can generate correct UUIDs in a very distant future.
On Sun, Feb 2, 2025 at 11:41 AM Sergey Prokhorenko
wrote:
>
> Dear colleagues,
>
> I would like to present for discussion my attached new draft documentation on
> UUID functions (Section 9.14. UUID Functions), which replaces the previously
> proposed draft at https://www.postgresql.org/docs/deve
On Sun, Feb 2, 2025 at 2:15 AM Andrey Borodin wrote:
>
>
>
> > On 31 Jan 2025, at 23:49, Masahiko Sawada wrote:
> >
> > Thank you for the patch! I agree with the basic direction of this fix.
> > Here are some review comments:
> >
> > ---
> > -static inline int64 get_real_time_ns_ascending();
> >
Dearcolleagues,
I wouldlike to present for discussion my attached new draft documentation on
UUIDfunctions (Section 9.14. UUID Functions), which replaces the
previouslyproposed draft at
https://www.postgresql.org/docs/devel/functions-uuid.html.I have preserved and
significantly supplemented t
> On 31 Jan 2025, at 23:49, Masahiko Sawada wrote:
>
> Thank you for the patch! I agree with the basic direction of this fix.
> Here are some review comments:
>
> ---
> -static inline int64 get_real_time_ns_ascending();
> +static inline uint64 get_real_time_ns_ascending();
>
> IIUC we don't n
On Thu, Jan 30, 2025 at 11:09 PM Andrey Borodin wrote:
>
>
>
> > On 31 Jan 2025, at 00:54, Masahiko Sawada wrote:
> >
> > I like this idea. Would you like to write a patch, or shall I?
>
> I propose to separate milliseconds from nanoseconds. Please find attached
> implementation of this.
> With
> On 31 Jan 2025, at 00:54, Masahiko Sawada wrote:
>
> I like this idea. Would you like to write a patch, or shall I?
I propose to separate milliseconds from nanoseconds. Please find attached
implementation of this.
With this patch we can generate correct UUIDs in a very distant future.
postg
On Thu, Jan 30, 2025 at 12:59 AM Andrey Borodin wrote:
>
>
>
> > On 12 Dec 2024, at 23:08, Masahiko Sawada wrote:
> >
> > Pushed
>
> Hi Masahiko!
>
> I’ve found some inconsistency in handling of overflow. I’m not sure we should
> handle it, but anyway.
Thank you for the report!
>
> postgres=#
> On 12 Dec 2024, at 23:08, Masahiko Sawada wrote:
>
> Pushed
Hi Masahiko!
I’ve found some inconsistency in handling of overflow. I’m not sure we should
handle it, but anyway.
postgres=# select x,
uuid_extract_timestamp(uuidv7((x::text || ' year'::text)::interval)),
(x::tex
Hi Daniel!
> On 16 Dec 2024, at 19:08, Daniel Verite wrote:
>
> The timestamps are now just a sequence incrementing by 1
> on each call, independently of the server's clock and
> the actual time span between calls. It has become a counter
> and will remain so until the backend terminates.
This
Andrey M. Borodin wrote:
> I've addressed all items, except formatting a table...
Sorry for not following up sooner.
To illustrate my point upthread that was left unaddressed, let's say
I have a server with an incorrect date in the future.
A session generates an uuid
postgres=# select
On Mon, Dec 9, 2024 at 7:42 PM Andrey M. Borodin wrote:
>
>
>
> > On 10 Dec 2024, at 03:34, Masahiko Sawada wrote:
> >
> > I've attached the updated patches.
>
> Both patches look good to me.
> I'm not sure, but, perhaps, commit message of unleakproofing a function
> should mention that the prob
> On 10 Dec 2024, at 03:34, Masahiko Sawada wrote:
>
> I've attached the updated patches.
Both patches look good to me.
I'm not sure, but, perhaps, commit message of unleakproofing a function should
mention that the problem was reported in Peter E. review.
Best regards, Andrey Borodin.
sha512(bytea)
-gen_random_uuid()
starts_with(text,text)
macaddr8_eq(macaddr8,macaddr8)
macaddr8_lt(macaddr8,macaddr8)
--
2.43.5
From cb7912a7d97e78253ce498d23224097cf2f5d895 Mon Sep 17 00:00:00 2001
From: "Andrey M. Borodin"
Date: Wed, 20 Mar 2024 22:30:14 +0500
Subject: [PATCH v
> On 2 Dec 2024, at 11:00, Masahiko Sawada wrote:
>
> The monotonicity of generated UUIDv7 is guaranteed only within a
> single backend.
I've addressed all items, except formatting a table... I can't build docs to
make a reasonable judgement if the table looks OK.
Changes:
- restored leakpro
On Sat, Nov 30, 2024 at 7:01 AM Daniel Verite wrote:
>
> Andrey M. Borodin wrote:
>
>
> > I'm sending amendments addressing your review as a separate step in patch
> > set. Step 1 of this patch set is identical to v39.
>
> Some comments about the implementation of monotonicity:
>
> +/*
> +
Andrey M. Borodin wrote:
> I'm sending amendments addressing your review as a separate step in patch
> set. Step 1 of this patch set is identical to v39.
Some comments about the implementation of monotonicity:
+/*
+ * Get the current timestamp with nanosecond precision for UUID generati
On Fri, Nov 29, 2024 at 12:17 PM Masahiko Sawada wrote:
>
> On Fri, Nov 29, 2024 at 11:47 AM Marcos Pegoraro wrote:
> >
> > Em sex., 29 de nov. de 2024 às 15:49, Masahiko Sawada
> > escreveu:
> >>
> >> uuidv7 () uuid
> >
> >
> > Wouldn't it be better to change this to
> > uuidv7 ([interval])
On Fri, Nov 29, 2024 at 11:47 AM Marcos Pegoraro wrote:
>
> Em sex., 29 de nov. de 2024 às 15:49, Masahiko Sawada
> escreveu:
>>
>> uuidv7 () uuid
>
>
> Wouldn't it be better to change this to
> uuidv7 ([interval]) uuid and explain what that param is ?
Yes, the function synopsis in the doc sh
Em sex., 29 de nov. de 2024 às 15:49, Masahiko Sawada
escreveu:
> uuidv7 () uuid
>
Wouldn't it be better to change this to
uuidv7 ([interval]) uuid
On Fri, Nov 29, 2024 at 10:39 AM Andrey M. Borodin wrote:
>
>
>
> > On 29 Nov 2024, at 00:46, Peter Eisentraut wrote:
> >
> > Here as well.
>
> Peter, many thanks for the next round of review. I agree with all corrections.
> I'm sending amendments addressing your review as a separate step in patc
> On 29 Nov 2024, at 00:46, Peter Eisentraut wrote:
>
> Here as well.
Peter, many thanks for the next round of review. I agree with all corrections.
I'm sending amendments addressing your review as a separate step in patch set.
Step 1 of this patch set is identical to v39.
Thanks!
Best reg
On Fri, Nov 29, 2024 at 5:59 AM Sergey Prokhorenko
wrote:
>
>
>
> Sergey Prokhorenko sergeyprokhore...@yahoo.com.au
>
>
> On Friday 29 November 2024 at 09:19:33 am GMT+3, Masahiko Sawada
> wrote:
>
>
> On Thu, Nov 28, 2024 at 8:13 PM Sergey Prokhorenko
>
> wrote:
> >
> > I mean to add not bench
> On 29 Nov 2024, at 18:57, Sergey Prokhorenko
> wrote:
>
> Workloads can and must be added with parameters. Typically, companies use
> test tables of 10,000 and 1,000,000 records, etc. Different companies have
> mostly similar usage scenarios (for example, incremental loading). Each
> com
Sergey Prokhorenko sergeyprokhore...@yahoo.com.au
On Friday 29 November 2024 at 09:19:33 am GMT+3, Masahiko Sawada
wrote:
On Thu, Nov 28, 2024 at 8:13 PM Sergey Prokhorenko
wrote:
>
> I mean to add not benchmark results to the patch, but functions so that
> everyone can compare the
On Thu, Nov 28, 2024 at 8:13 PM Sergey Prokhorenko
wrote:
>
> I mean to add not benchmark results to the patch, but functions so that
> everyone can compare themselves on their equipment. The comparison with
> UUIDv4 is not very interesting, as the choice is usually between UUIDv7 and
> an inte
On Fri, 29 Nov 2024, 09:14 Sergey Prokhorenko, <
sergeyprokhore...@yahoo.com.au> wrote:
> I mean to add not benchmark results to the patch, but functions so that
> everyone can compare themselves on their equipment. The comparison with
> UUIDv4 is not very interesting, as the choice is usually bet
I mean to add not benchmark results to the patch, but functions so that
everyone can compare themselves on their equipment. The comparison with UUIDv4
is not very interesting, as the choice is usually between UUIDv7 and an integer
key. And I have described many use cases, and in your benchmark t
On 27.11.24 00:11, Masahiko Sawada wrote:
On Tue, Nov 26, 2024 at 1:55 PM Jelte Fennema-Nio wrote:
On Tue, 26 Nov 2024 at 21:48, Sergey Prokhorenko
wrote:
gen_uuidv7() is OK
I'd very much prefer to not have a gen_ or get_ prefix as argued before[1][2].
My vote is still for simply uuidv7()
> On 28 Nov 2024, at 04:07, Sergey Prokhorenko
> wrote:
>
> It would be useful to add a standard comparative benchmark with several
> parameters and use cases to the patch, so that IT departments can compare
> UUIDv7, ULID, UUIDv4, Snowflake ID and BIGSERIAL for their hardware and
> condit
I forgot to mention the incremental download
Отправлено из Yahoo Почты на iPhone
Пользователь четверг, ноября 28, 2024, 2:07 AM написал Sergey Prokhorenko
:
It would be useful to add a standard comparative benchmark with several
parameters and use cases to the patch, so that IT departments c
It would be useful to add a standard comparative benchmark with several
parameters and use cases to the patch, so that IT departments can compare
UUIDv7, ULID, UUIDv4, Snowflake ID and BIGSERIAL for their hardware and
conditions.
I know for a fact that IT departments make such benchmarks of low
On Tue, Nov 26, 2024 at 7:11 PM Andrey Borodin wrote:
>
>
>
> > On 27 Nov 2024, at 04:11, Masahiko Sawada wrote:
> >
> > On Tue, Nov 26, 2024 at 1:55 PM Jelte Fennema-Nio
> > wrote:
> >>
> >> On Tue, 26 Nov 2024 at 21:48, Sergey Prokhorenko
> >> wrote:
> >>> gen_uuidv7() is OK
> >>
> >> I'd ve
> On 27 Nov 2024, at 04:11, Masahiko Sawada wrote:
>
> On Tue, Nov 26, 2024 at 1:55 PM Jelte Fennema-Nio wrote:
>>
>> On Tue, 26 Nov 2024 at 21:48, Sergey Prokhorenko
>> wrote:
>>> gen_uuidv7() is OK
>>
>> I'd very much prefer to not have a gen_ or get_ prefix as argued
>> before[1][2].
>
On Tue, Nov 26, 2024 at 1:55 PM Jelte Fennema-Nio wrote:
>
> On Tue, 26 Nov 2024 at 21:48, Sergey Prokhorenko
> wrote:
> > gen_uuidv7() is OK
>
> I'd very much prefer to not have a gen_ or get_ prefix as argued before[1][2].
>
> My vote is still for simply uuidv7() and uuidv4()
>
> > uuid-ossp is
On Tue, 26 Nov 2024 at 21:48, Sergey Prokhorenko
wrote:
> gen_uuidv7() is OK
I'd very much prefer to not have a gen_ or get_ prefix as argued before[1][2].
My vote is still for simply uuidv7() and uuidv4()
> uuid-ossp is outdated, slow and not supported by the author. UUIDv7 is the
> renaissan
gen_uuidv7() is OK
uuid-ossp is outdated, slow and not supported by the author. UUIDv7 is the
renaissance of UUIDs. So we should not depend on legacy technology names
Sergey Prokhorenko sergeyprokhore...@yahoo.com.au
On Tuesday 26 November 2024 at 10:35:20 pm GMT+3, Przemysław Sztoch
wr
A lot of people use https://www.postgresql.org/docs/current/uuid-ossp.html.
|And `uuid_generate_v7()` will be the continuation...|
|From my point of view, absorbing uuid_generate_v5 into mainline would
be a great move too.
|
On 26.11.2024 20:30, Masahiko Sawada wrote:
On Tue, Nov 26, 2024 at
On Tue, Nov 26, 2024 at 11:11 AM Sergey Prokhorenko
wrote:
>
> Changing the name uuidv7() to uuid_v7() is a bad idea because the RFC 9562
> uses the term UUIDv7, and therefore code containing uuid_v7() will not be
> found by searching the web in most cases.
>
> It makes much more sense to rename
time() and 10 bits.
> Anything else - clock_gettime() and 12 bits.
>
Thank you for the summary.
On MinGW, IIUC we can get 100-ns precision timestamps[1], so using 12
bits for calculating the minimal step would make sense.
Also, if we implement the Windows port of clock_gettime() in the
fu
gt; MinGW - we use clock_gettime() and 12 bits.
>> Darwin - we use clock_gettime() and 10 bits.
>> Anything else - clock_gettime() and 12 bits.
>>
>
> Thank you for the summary.
>
> On MinGW, IIUC we can get 100-ns precision timestamps[1], so using
> On 26 Nov 2024, at 01:11, Masahiko Sawada wrote:
>
> I've merged patches and renamed functions (also updated the commit
> message). Please find the attachment.
This comment
* On MacOS real time is truncated to microseconds.
should also note that on Windows we use ported version of gettimeof
; 10 bits of sub-ms.
> MinGW - we use clock_gettime() and 12 bits.
> Darwin - we use clock_gettime() and 10 bits.
> Anything else - clock_gettime() and 12 bits.
>
Thank you for the summary.
On MinGW, IIUC we can get 100-ns precision timestamps[1], so using 12
bits for calcula
nd 10
bits of sub-ms.
MinGW - we use clock_gettime() and 12 bits.
Darwin - we use clock_gettime() and 10 bits.
Anything else - clock_gettime() and 12 bits.
>
> In get_real_time_ns_ascending(), we use _MSC_VER so we use
> clock_gettime() on MinGW.
>
>>
>> Sergey Prokhoren
f
Is there a reason for using different macros?
In get_real_time_ns_ascending(), we use _MSC_VER so we use
clock_gettime() on MinGW.
>
> Sergey Prokhorenko just draw my attention to the new release of MariaDB [0].
> They are doing very similar UUID v7 generation as we do [1].
>
T
mment.
>
> Sergey Prokhorenko just draw my attention to the new release of MariaDB
> [0]. They are doing very similar UUID v7 generation as we do [1].
>
>
> Best regards, Andrey Borodin.
>
>
> [0]
> https://mariadb.com/resources/blog/announcing-mariadb-community-serve
improved comment.
Sergey Prokhorenko just draw my attention to the new release of MariaDB [0].
They are doing very similar UUID v7 generation as we do [1].
Best regards, Andrey Borodin.
[0]
https://mariadb.com/resources/blog/announcing-mariadb-community-server-11-7-rc-with-vector-searc
ached an updated patch that squashed changes I made for v33.
We're still discussing increasing entropy on Windows and macOS, but
the patch seems to be in good shape.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
v36-0001-Implement-UUID-v7.patch
Description: Binary data
On Thu, Nov 21, 2024 at 1:22 PM Andrey M. Borodin wrote:
>
>
>
> > On 21 Nov 2024, at 02:24, Masahiko Sawada wrote:
> >
> > But does replacing the least significant 2 bits
> > with random 2 bits really not affect monotonicity?
>
> You are right. We have to take into account this when calculating
> On 21 Nov 2024, at 02:24, Masahiko Sawada wrote:
>
> But does replacing the least significant 2 bits
> with random 2 bits really not affect monotonicity?
You are right. We have to take into account this when calculating monotonicity.
PFA another version.
Best regards, Andrey Borodin.
v
On Tue, Nov 19, 2024 at 7:54 PM Andrey M. Borodin wrote:
>
>
>
> > On 20 Nov 2024, at 00:06, Masahiko Sawada wrote:
> >
> > On Tue, Nov 19, 2024 at 9:45 AM Andrey M. Borodin
> > wrote:
> >>
> >>
> >>
> >>> On 19 Nov 2024, at 14:31, Andrey M. Borodin wrote:
> >>>
> >>> Done.
> >>
> >> Here's v3
> On 20 Nov 2024, at 00:06, Masahiko Sawada wrote:
>
> On Tue, Nov 19, 2024 at 9:45 AM Andrey M. Borodin
> wrote:
>>
>>
>>
>>> On 19 Nov 2024, at 14:31, Andrey M. Borodin wrote:
>>>
>>> Done.
>>
>> Here's v33 intact + one more patch to add 2 bits of entropy on MacOS (to
>> compensate
On Tue, Nov 19, 2024 at 9:45 AM Andrey M. Borodin wrote:
>
>
>
> > On 19 Nov 2024, at 14:31, Andrey M. Borodin wrote:
> >
> > Done.
>
> Here's v33 intact + one more patch to add 2 bits of entropy on MacOS (to
> compensate lack of nanoseconds).
> What do you think?
>
Thank you for updating the p
> On 19 Nov 2024, at 14:31, Andrey M. Borodin wrote:
>
> Done.
Here's v33 intact + one more patch to add 2 bits of entropy on MacOS (to
compensate lack of nanoseconds).
What do you think?
Best regards, Andrey Borodin.
v33-0001-Implement-UUID-v7.patch
Description: Binary d
gettimeofday() on Windows, and then don't change anything
> in instr_time.h? We need to explain why we don't use gettimeofday() on
> unix-like systems in get_real_time_ns() function.
Done.
Best regards, Andrey Borodin.
v33-0001-Implement-UUID-v7.patch
Description: Binary data
On Sun, Nov 17, 2024 at 10:39 AM Andrey M. Borodin wrote:
>
>
>
> > On 17 Nov 2024, at 00:06, Andrey M. Borodin wrote:
> >
> > v31
>
> There was a problem with MingWG build. I've considered all options and
> decided to include all necessary stuff into instr_time.h. So much fuss for
> these 2 bi
in.
v32-0001-Implement-UUID-v7.patch
Description: Binary data
sion or variant) and mix it into
increased_clock_precision on MacOS?
Thank you!
Best regards, Andrey Borodin.
v31-0001-Implement-UUID-v7.patch
Description: Binary data
On Mon, Nov 11, 2024 at 12:20 PM Masahiko Sawada wrote:
>
> On Sat, Nov 9, 2024 at 9:07 AM Sergey Prokhorenko
> wrote:
> >
> > On Saturday 9 November 2024 at 01:00:15 am GMT+3, Masahiko Sawada
> > wrote:
> >
> > > the microsecond part is working also as a counter in a sense. IT seems
> > > fin
On Sat, Nov 9, 2024 at 9:07 AM Sergey Prokhorenko
wrote:
>
> On Saturday 9 November 2024 at 01:00:15 am GMT+3, Masahiko Sawada
> wrote:
>
> > the microsecond part is working also as a counter in a sense. IT seems fine
> > to me but I'm slightly concerned that there is no guidance of such
> > i
On Saturday 9 November 2024 at 01:00:15 am GMT+3, Masahiko Sawada
wrote:
> the microsecond part is working also as a counter in a sense. IT seems fine
> to me but I'm slightly concerned that there is no guidance of such
> implementation in RFC 9562.
In fact, there is guidance of similar impleme
On Thu, Nov 7, 2024 at 12:34 AM Andrey M. Borodin wrote:
>
>
>
> > On 7 Nov 2024, at 12:42, Masahiko Sawada wrote:
> >
> > On Wed, Nov 6, 2024 at 10:14 AM Andrey M. Borodin
> > wrote:
> >>
> >>
> >>
> >>> On 5 Nov 2024, at 23:56, Andrey M. Borodin wrote:
> >>>
> >>>
> >>
> >> Some more though
. See version
> > v24-0001-Implement-UUID-v7.patch
> > This version is more resilent to generating a lot of UUIDs on one backend
> > while still not accumulating time shift.
> > Yet, UUIDs generated on parallel workers will loose some sortability.
>
> > Personall
On Thursday 7 November 2024 at 11:34:31 am GMT+3, Andrey M. Borodin
wrote:
> 12 bits does not differ much. We can have much longer counters. Before
> switching to Method 3 I used 18 bits counter. See version
> v24-0001-Implement-UUID-v7.patch> This version is more resilent to gen
its are
>> initialized with a random number, which reduces the risk of collision.
>
> I feel that it's better to switch to Method 1 or 2 with 12 bits or
> larger counter space.
>
12 bits does not differ much. We can have much longer counters. Before
switching to Met
On Wed, Nov 6, 2024 at 10:14 AM Andrey M. Borodin wrote:
>
>
>
> > On 5 Nov 2024, at 23:56, Andrey M. Borodin wrote:
> >
> >
>
> Some more thoughts on this patch version:
>
> 0. Comment mentioning nanoseconds, while we do not need to carry anything
> /* Convert TimestampTz back and carry nanosec
> On 5 Nov 2024, at 23:56, Andrey M. Borodin wrote:
>
>
Some more thoughts on this patch version:
0. Comment mentioning nanoseconds, while we do not need to carry anything
/* Convert TimestampTz back and carry nanoseconds. */
1. There's unnecessary &3 in
uuid->data[7] = uuid->data[7] | ((u
not succeeded.
Let's use only microseconds.
Best regards, Andrey Borodin.
v30-0001-Implement-UUID-v7.patch
Description: Binary data
On Fri, Nov 1, 2024 at 10:33 AM Andrey M. Borodin wrote:
>
>
>
> > On 31 Oct 2024, at 23:04, Stepan Neretin wrote:
> >
> >
> > Firstly, I'd like to discuss the increased_clock_precision variable, which
> > currently divides the timestamp into milliseconds and nanoseconds. However,
> > this approa
> On 31 Oct 2024, at 23:04, Stepan Neretin wrote:
>
>
> Firstly, I'd like to discuss the increased_clock_precision variable, which
> currently divides the timestamp into milliseconds and nanoseconds. However,
> this approach only approximates the extra bits for sub-millisecond
> precision, le
On Thu, Oct 31, 2024 at 9:53 PM Andrey M. Borodin wrote:
>
>
>
> > On 1 Nov 2024, at 03:00, Masahiko Sawada wrote:
> >
> > Therefore, if the
> > system clock moves backward due to NTP, we cannot guarantee
> > monotonicity and sortability. Is that right?
>
> Not exactly. Monotonicity is ensured fo
> On 1 Nov 2024, at 03:00, Masahiko Sawada wrote:
>
> Therefore, if the
> system clock moves backward due to NTP, we cannot guarantee
> monotonicity and sortability. Is that right?
Not exactly. Monotonicity is ensured for a given backend. We make sure that
timestamp is advanced at least for
>> providing implementation, it's trivial. PFA patch with implementation.
> >>
> >
> > My point is that we should either support full functionality for
> > UUIDv6 (such as generation and extraction) or none of them. I'm not
> > really sure we want UU
> > I think we typically avoid this kind of check failure by assigning
> > uuidv7() and uuidv7(interval) different C functions that call the
> > common function. That is, we have pg_proc entries like:
> >
>
> Done.
>
> >>>
> >>> It's odd to me that only uuid_extract_timestamp() supports UUID v6 in
y for
> UUIDv6 (such as generation and extraction) or none of them. I'm not
> really sure we want UUIDv6 as well, but if we want it, it should be
> implemented in a separate patch.
Make sense. I've removed all traces of v6.
Thanks!
Best regards, Andrey Borodin.
v29-0001-Implement-UUID-v7.patch
Description: Binary data
On Sat, Oct 26, 2024 at 10:05 AM Andrey M. Borodin wrote:
>
> >
> > ---
> > - oid | proname | oid | proname
> > --+-+-+-
> > -(0 rows)
> > + oid | proname | oid | proname
> > +--+-+--+-
> > + 9896 | uuidv7 | 9897 | uuidv7
> > +(1 row)
> >
> > I th
]) & 0xf) << 8;
> + tms += ((uint64) uuid->data[7]);
> +
> + /* convert 100-ns intervals to us, then adjust */
> + ts = (TimestampTz) (tms / 10) -
> + ((uint64) POSTGRES_EPOCH_JDATE - GREGORIAN_EPOCH_JDATE) *
> SECS_PER_DAY * USECS_PER_SEC;
> +
> + PG_RETURN_TIMESTAMPTZ(ts);
> + }
>
> It's odd to me that only uuid_extract_timestamp() supports UUID v6 in
> spite of not supporting UUID v6 generation. I think it makes more
> sense to support UUID v6 generation as well, if the need for it is
> high.
RFC urges to use UUIDv7 instead of UUIDv6 when possible. I'm fine with
providing implementation, it's trivial. PFA patch with implementation.
Best regards, Andrey Borodin.
v28-0001-Implement-UUID-v7.patch
Description: Binary data
> On 16 Oct 2024, at 11:05, Michael Paquier wrote:
>
> This part of the patch looks structurally wrong to me because we've
> already spent some time refactoring the clock APIs into instr_time.h
> that deals about cross-platform requirements for monotonic times.
> Particularly, on MacOS, we hav
On Sun, Aug 4, 2024 at 3:51 AM Andrey M. Borodin wrote:
>
>
>
> > On 28 Jul 2024, at 23:44, Andrey M. Borodin wrote:
> >
> > PFA version accepting offset interval.
>
> There was a bug: when time was not moving on, I was updating used time by a
> nanosecond, instead of 1/4096 of millisecond.
> V2
On Sun, Aug 04, 2024 at 03:50:37PM +0500, Andrey M. Borodin wrote:
> There was a bug: when time was not moving on, I was updating used
> time by a nanosecond, instead of 1/4096 of millisecond.
> V27 fixes that.
+static uint64 get_real_time_ns()
+{
+ struct timespec tmp;
+
+ clock_gett
v27-0001-Implement-UUID-v7.patch
Description: Binary data
is:
postgres=# select uuidv7(interval '-2 months’);
018fc02f-0996-7136-aeb4-8936b5a516a1
postgres=# select uuid_extract_timestamp(uuidv7(interval '-2 months'));
2024-05-28 22:11:15.71+05
What do you think?
Best regards, Andrey Borodin.
v26-0001-Implement-UUID-v7.patch
Description: Binary data
Dear Colleagues,
Althoughthe uuidv7(timestamp) function clearly contradicts RFC 9562, but
theuuidv7(timestamp_offset) function is fully compliant with RFC 9562 and
isabsolutely necessary.
Here is a quote from the RFC 9562to support thisstatement (RFC 9562:
Universally Unique IDentifiers (UUIDs
Thanks!
Best regards, Andrey Borodin.
[0]
https://www.postgresql.org/message-id/flat/be0339cc-1ae1-4892-9445-8e6d8995a44d%40eisentraut.org
v25-0001-Implement-UUID-v7.patch
Description: Binary data
> On 3 May 2024, at 11:18, Andrey M. Borodin wrote:
>
> RFC 9562 is not in AUTH48-Done state, it was approved by authors and editor,
> and now should be published.
It's RFC now.
https://datatracker.ietf.org/doc/rfc9562/
Best regards, Andrey Borodin.
> On 3 May 2024, at 11:18, Andrey M. Borodin wrote:
>
Here's the documentation from ClickHouse [0] for their implementation. It's
identical to provided patch in this thread, with few notable exceptions:
1. Counter is 42 bits, not 18. The counter have no guard bits, every bit is
initialized
> On 13 Apr 2024, at 11:58, Andrey M. Borodin wrote:
>
> New UUID is assigned RFC number 9562, it was aproved by RFC editors and is
> now in AUTH48 state.
RFC 9562 is not in AUTH48-Done state, it was approved by authors and editor,
and now should be published.
Best regards, Andrey Borodin.
On Sat, Apr 13, 2024 at 07:07:34PM +, Sergey Prokhorenko wrote:
> I think that for the sake of such an epoch-making thing as UUIDv7 it
> would be worth slightly unfreezing this feature freeze.
A feature freeze is here to freeze things in place. This comes up
every year, and that won't happen.
1 - 100 of 230 matches
Mail list logo
