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
On Sun, Feb 16, 2025 at 6:21 PM 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 Whether and Which UUID to Use" would be better suited for Chapter
> 8: "Data
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.
On Wed, Dec 4, 2024 at 9:04 AM Andrey M. Borodin wrote:
>
>
>
> > 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
> 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
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 it to get_uuidv7(), so that a query for
"uuidv7" does not return a bu
On Mon, 25 Nov 2024 at 12:11, Masahiko Sawada wrote:
> On Mon, Nov 25, 2024 at 10:15 AM Andrey M. Borodin
> wrote:
>>
>>
>>
>> > On 25 Nov 2024, at 22:53, Masahiko Sawada wrote:
>> >
>> > In the following code, we use "defined(__darwin__) || defined(_MSC_VER)":
>> >
>> > +#if defined(__darwin__
> 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
On Mon, Nov 25, 2024 at 10:15 AM Andrey M. Borodin wrote:
>
>
>
> > On 25 Nov 2024, at 22:53, Masahiko Sawada wrote:
> >
> > In the following code, we use "defined(__darwin__) || defined(_MSC_VER)":
> >
> > +#if defined(__darwin__) || defined(_MSC_VER)
> > +#define SUBMS_MINIMAL_STEP_BITS 10
> >
> On 25 Nov 2024, at 22:53, Masahiko Sawada wrote:
>
> In the following code, we use "defined(__darwin__) || defined(_MSC_VER)":
>
> +#if defined(__darwin__) || defined(_MSC_VER)
> +#define SUBMS_MINIMAL_STEP_BITS 10
> +#else
> +#define SUBMS_MINIMAL_STEP_BITS 12
> +#endif
> #define SUBMS_BIT
On Sat, Nov 23, 2024 at 12:20 AM Andrey M. Borodin wrote:
>
>
>
> > On 23 Nov 2024, at 10:58, Masahiko Sawada wrote:
> >
> > I've attached 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 go
HI Andrey M. Borodin
It's not just mariadb, percona also implements the uuid plugin.
https://docs.percona.com/percona-server/8.4/uuid-versions.html#functions-available-in-uuid_vx
Thanks
Andrey M. Borodin 于2024年11月23日周六 16:21写道：
>
>
> > On 23 Nov 2024, at 10:58, Masahiko Sawada wrote:
> >
> On 23 Nov 2024, at 10:58, Masahiko Sawada wrote:
>
> I've attached 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.
+1, thanks!
PFA version with improved comment.
Sergey Prokh
On Fri, Nov 22, 2024 at 2:37 PM Masahiko Sawada wrote:
>
> 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 monoto
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 data
v34-0002-Mi
> On 19 Nov 2024, at 02:16, Masahiko Sawada wrote:
>
> I realized that what we do in get_real_time_ns() on Windows is
> essentially the same as what we do in gettimeofday(). Probably we can
> just do either clock_gettime() with CLOCK_REALTIME on unix-like
> systems and gettimeofday() on Windows
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
> 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 bits
about nanoseconds :)
Best regards, Andrey Borodin.
v32-0001-Implemen
> On 15 Nov 2024, at 06:44, Masahiko Sawada wrote:
>
> IIUC v29 patch implements UUIDv7 generation in this way. So I've
> reviewed v29 patch and here are some review comments:
I believe I've addressed all your comments in v31 with one exception:
get_clock_timestamp_ns() does not return ascendin
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
On Fri, Nov 8, 2024 at 1:25 PM Sergey Prokhorenko
wrote:
>
> 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-Im
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 generating
> a l
> 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 thoughts on this patch version:
>>
>> 0. Comment mentioning nanoseconds, while we do
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
> On 2 Nov 2024, at 02:23, Masahiko Sawada wrote:
>
> Most of the timing durations were nanoseconds and fell into either 0
> ns. Others fell into >1023 bins.
Indeed. We cannot have these 2 bits from nanoseconds :(
I've tried to come up with some clever tricks, but have not succeeded.
Let's use
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
On Thu, Oct 31, 2024 at 11:46 AM Andrey M. Borodin wrote:
>
>
>
> > On 31 Oct 2024, at 22:15, Masahiko Sawada wrote:
> >
> > On Sat, Oct 26, 2024 at 10:05 AM Andrey M. Borodin
> > wrote:
> >
> > I think we typically avoid this kind of check failure by assigning
> > uuidv7() and uuidv7(interval)
> > 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
> On 31 Oct 2024, at 22:15, Masahiko Sawada wrote:
>
> On Sat, Oct 26, 2024 at 10:05 AM Andrey M. Borodin
> wrote:
>
> 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
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
Thanks for the review!
> On 18 Oct 2024, at 02:16, Masahiko Sawada wrote:
>
> 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 mov
> 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
> 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.
V27 fixes that.
Thanks!
Best regards, Andrey Borodin.
v27-0001-Impleme
> On 24 Jul 2024, at 04:09, Sergey Prokhorenko
> wrote:
>
> Implementations MAY alter the actual timestamp.
Hmm… looks like we slightly misinterpreted words about clock source.
Well, that’s great, let’s get offset back.
PFA version accepting offset interval.
It works like this:
postgres=# sel
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
> On 8 May 2024, at 18:37, Andrey M. Borodin wrote:
>
> It's RFC now.
PFA version with references to RFC instead of drafts.
In nearby thread [0] we found out that most systems have enough presicion to
fill additional 12 bits of sub-millisecond information. So I switched
implementation to thi
> 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 229 matches
Mail list logo
