> 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.
I think that for the sake of such an epoch-making thing as UUIDv7 it would be
worth slightly unfreezing this feature freeze.
Best regards,
Sergey prokhorenkosergeyprokhore...@yahoo.com.au
On Saturday, 13 April 2024 at 09:58:29 am GMT+3, Andrey M. Borodin
wrote:
> On 12 Mar 2024,
> On 12 Mar 2024, at 20:41, Jelte Fennema-Nio wrote:
>
> if e.g.
> the RFC got approved 2 weeks after Postgres its feature freeze
Jelte, you seem to be the visionary! I would consider participating in
lotteries or betting.
New UUID is assigned RFC number 9562, it was aproved by RFC editors a
For every complex problem there is an answer that is clear, simple, and wrong.
Since the RFC allows microsecond timestamp granularity, the first thing that
comes to everyone's mind is to insert microsecond granularity into UUIDv7. And
if the RFC allowed nanosecond timestamp granularity, then the
> On 4 Apr 2024, at 18:45, Peter Eisentraut wrote:
>
> On 26.03.24 18:26, Andrey M. Borodin wrote:
>>> Also, you are initializing 4 bits (I think?) to zero to guard against
>>> counter rollovers (so it's really just an 8 bit counter?). But nothing
>>> checks against such rollovers, so I don
On 26.03.24 18:26, Andrey M. Borodin wrote:
Also, you are initializing 4 bits (I think?) to zero to guard against counter
rollovers (so it's really just an 8 bit counter?). But nothing checks against
such rollovers, so I don't understand the use of that.
No, there's only one guard rollover bi
64 etc. instead of uint64_t etc.
>
> - It seems the added includes
>
> #include "access/xlog.h"
> #include "utils/builtins.h"
> #include "utils/datetime.h"
>
> are not needed.
>
> - The static variables sequence_counter and previous_timestamp could be kept
> inside the uuidv7() function.
Fixed.
Thanks!
Best regards, Andrey Borodin.
v24-0001-Implement-UUID-v7.patch
Description: Binary data
On 20.03.24 19:08, Andrey M. Borodin wrote:
On 19 Mar 2024, at 13:55, Peter Eisentraut wrote:
On 16.03.24 18:43, Andrey M. Borodin wrote:
On 15 Mar 2024, at 14:47, Aleksander Alekseev wrote:
+1 to the idea. I doubt that anyone will miss it.
PFA v22.
Changes:
1. Squashed all editorialisation
Another source: Microservices Pattern: Database per service
|
|
|
| | |
|
|
|
| |
Microservices Pattern: Database per service
A service's database is private to that service
|
|
|
Sergey Prokhorenko sergeyprokhore...@yahoo.com.au
On Friday, 22 March 2024 at 04:58:59 pm
BTW: Each microservice should have its own database to ensure data isolation
and independence, enabling better scalability and fault tolerance
Source: Microservices Pattern: Shared database
|
|
| |
Microservices Pattern: Shared database
|
|
|
Sergey Prokhorenko sergeyprokhore...@y
Why not use a single UUID generator for the database table in this case,
similar to autoincrement?
Sergey Prokhorenko
sergeyprokhore...@yahoo.com.au
On Friday, 22 March 2024 at 03:51:20 pm GMT+3, Peter Eisentraut
wrote:
On 21.03.24 16:21, Jelte Fennema-Nio wrote:
> On Wed, 20 Mar 20
On 21.03.24 16:21, Jelte Fennema-Nio wrote:
On Wed, 20 Mar 2024 at 19:08, Andrey M. Borodin wrote:
Timer-based bits contribute to global sortability. But the real timers we have
are not even millisecond adjusted. We can hope for ~few ms variation in one
datacenter or in presence of atomic clo
I think it's better to leave Andrey's patch as is, and add another function in
the future with a customizable UUIDv7 structure for special use cases. The
structure description can be in JSON format. See this discussion.
Sergey Prokhorenko sergeyprokhore...@yahoo.com.au
On Friday, 22 March
> On 21 Mar 2024, at 20:21, Jelte Fennema-Nio wrote:
>
> On Wed, 20 Mar 2024 at 19:08, Andrey M. Borodin wrote:
>> Timer-based bits contribute to global sortability. But the real timers we
>> have are not even millisecond adjusted. We can hope for ~few ms variation in
>> one datacenter or i
On Wed, 20 Mar 2024 at 19:08, Andrey M. Borodin wrote:
> Timer-based bits contribute to global sortability. But the real timers we
> have are not even millisecond adjusted. We can hope for ~few ms variation in
> one datacenter or in presence of atomic clocks.
I think the main benefit of using m
wards.
I think that microseconds are good only for hardware-specific solutions, not
for something that runs on variety of platforms, OSes, devices.
Best regards, Andrey Borodin.
v23-0001-Implement-UUID-v7.patch
Description: Binary data
On 16.03.24 18:43, Andrey M. Borodin wrote:
On 15 Mar 2024, at 14:47, Aleksander Alekseev wrote:
+1 to the idea. I doubt that anyone will miss it.
PFA v22.
Changes:
1. Squashed all editorialisation by Jelte
2. Fixed my erroneous comments on using Method 2 (we are using method 1 instead)
3. R
ll traces of uuid_extract_variant()
Thanks!
Best regards, Andrey Borodin.
v22-0001-Implement-UUID-v7.patch
Description: Binary data
Hi,
> > So maybe we don't need the _extract_variant function?
>
> I think it's the best possible solution. The variant has no value besides
> detecting if a version can be extracted.
+1 to the idea. I doubt that anyone will miss it.
--
Best regards,
Aleksander Alekseev
1 - 100 of 212 matches
Mail list logo
