> On 6 Jul 2023, at 21:38, Peter Eisentraut <peter.eisentr...@enterprisedb.com> > wrote: > > I think it would be reasonable to review this patch now. +1.
Also, I think we should discuss UUID v8. UUID version 8 provides an RFC-compatible format for experimental or vendor-specific use cases. Revision 1 of IETF draft contained interesting code for v8: almost similar to v7, but with fields for "node ID" and "rolling sequence number". I think this is reasonable approach, thus I attach implementation of UUID v8 per [0]. But from my point of view this implementation has some flaws. These two new fields "node ID" and "sequence" are there not for uniqueness, but rather for data locality. But they are placed at the end, in bytes 14 and 15, after randomly generated numbers. I think that "sequence" is there to help generate local ascending identifiers when the real time clock do not provide enough resolution. So "sequence" field must be placed after 6 bytes of time-generated identifier. On a contrary "node ID" must differentiate identifiers generated on different nodes. So it makes sense to place "node ID" before timing. So identifiers generated on different nodes will tend to be in different ranges. Although, section "6.4. Distributed UUID Generation" states that "node ID" is there to decrease the likelihood of a collision. So my intuition might be wrong here. Do we want to provide this "vendor-specific" UUID with tweaks for databases? Or should we limit the scope with well defined UUID v7? Best regards, Andrey Borodin. [0] https://datatracker.ietf.org/doc/html/draft-ietf-uuidrev-rfc4122bis-01
v2-0001-Implement-UUID-v7-and-v8-as-per-IETF-draft.patch
Description: Binary data
