Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rk5lt-00AFO1-Ae for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Mar 2024 17:18:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rk5lq-00Gf7W-7D for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Mar 2024 17:18:34 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rk5ln-00Geyb-HW for pgsql-hackers@lists.postgresql.org; Tue, 12 Mar 2024 17:18:34 +0000 Received: from sonic318-20.consmr.mail.gq1.yahoo.com ([98.137.70.146]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rk5li-0049KV-Uy for pgsql-hackers@postgresql.org; Tue, 12 Mar 2024 17:18:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1710263903; bh=wBaFHThH6VGu24SqfJxOCTTwNGJ4T42BWy413LH/u40=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=KAglrw47eyQ5yzoszLB0oVNuV3w98h7sKwJLKwLNMXne46V/gZrmyj60SWkW8+fbUffrnZ6yHbzvjf+6EKrmtLN9OTjttlccuSg/K9jwu/GEax8QWrvb6+XukKfA7RtqGCQ0JxihlMQGICCKmKrct/P2e2r6idBlVOvz2kIDxEKq8TMIEiyQ0S/NjyhY42TPyia05FUb7Zu7WG8dDjEiebxQVW5KaRohpVLLLLsKOnayv5GLlOgWcvmMb43bGKwToUk86CXPHi37jm6qEp3vo71ceMyfrnOF6yGlnRnSjaiHhNfIv3GqQWpBXLeiNvHO+Eu2kc7VMEUZoFY9d2ZxWw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1710263903; bh=Kd8bMN1PYR58EWJkRohlD23cfPmO2FyvVgtXG/7tsKO=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=qnj4q2ti1FfI4/0xgvaUnLskcjK7+UbBk3ZI1cC8iF7TZQv+YdyASlFlq9zhlVldKC5OwJUDAZOuNRT6h04tW4OSAtXviWaOrA5cV94WBal8Q6oTqmWk7+xlzJxOmDUSO4D+9YA9e2cstuto8w460uvk6RXnQ8mu7p1VztXQRJSaYfCKE600mjkUrowQJypA0Ou3IHIB0ElGmZxZzpKVsxmWyG0p843HcPDrRrSN7R4jE5oFcuLuiSJm3CThEM2rQTeuo13oI0D5Nz/CxL0k03jcz/k10rJfUw8sC39cQWjvC2UDlIA6X7rFxuKTdvg/hd2yuhYt6RGz5flysJqr0Q== X-YMail-OSG: W6mEqwAVM1l7rTORDSoPNSzYP22bVOsjMcBBO5.rWiJscwa2Xw92smS9.fNRk3b bVtFbI7jB7867PeqkLMBXp7SDU86Pj4gQrnL3n_LAnkqvPKkvMyNLlCIsYPTo7eb4TGLepoE2KND OmAI7RRr8QLeKt7TmdzpScyRb1mpScIhlDCupEwQ_TnYX7Wo_SHsdEOVOWMCU9rueyXL3dLmWvq1 CryBB3gJ89oOChPgM0l9QiHOKil7rBm8PnLDApjngEVbrWITxAhOsQlam1jjYsephtKKobFXn.BV .O7KRtQJ5Hc8EJoE0FQV7WCGhP4BSLZUs.g6cOJL2YsNItKI7HdXRdiVUX4dxXqvCfYKdxjdkXnK XuRdfd5.JhxzMr45nXbLQDVU2UNCec7KFvEtiRsqa8YmeUbbWdEkPOp93Eelw5Ol2ng6OBDibpsK E0F7Edfcv9BH1kDmyZU0acaP1n71eaodCm52Dmx6mtQ.c5pOTJgkJUNzIgDhvN8S0vaDsj7gf1f. B8hqMKzy1Ij_fFfTRLp_8.BPAzVooKbJfrW8H_svES8Md0vWGgIvptzvUWDtyYBOYmjfx5Dc4wNQ napMnH7rgIPsjMVp9JIhf.9UvXIfKbWSeYtXTLYcvxaClsvnr_SRDS4l6SREEszmjbMsOnOG9KUe DpMIhsWBOK_erlLByVl4rlz.ASMtu9MseDZ.xAPBWu_OVDOXTKPp2j6XL_OGhVLnoQs0SnEo5ZFW V73RSVLwbOcplikuKCcmdof72pT1b83FA0tGanMp3qWP7b4cuOKua7U_CsX9GJOyXtGclviVUBzW QwedhJ9nK4N_E9aRJ2j.5o_xaclUIdM.eTKU63z86VPPi3Z9C9MCWxOI6Pp0Ctvlboue4HpPVMox SbmBzo5mW2GPF2v_CzpkiFhWqUsVHBEYzi0jj_h3.esLc1Nd9pcaRUB749KEh7Q0EWi.Ce5hs6aC NLuwwHh6PCL3SwgXPG_amlOkocNxbwlOeSwr6ovS6CofL1E0OsTFQiBHXtw5H261gNjcPeI3mXIt oikRB2FP3Fw5398l0O.7XVbvkW_mSGTYgKGtEJ6MdeCVY9X16Gyhjt6ml9pj6WsFZ0G2NDMy0sMN lcU2TpTHHzPH6Rzi4P1X3x5QDIUXZgOlWE8QTRpL3fsVaW_VpQPTHwKomtNrpsq4mtnzkToonep_ 1Arvvc_kTpioV2tflzEvFPScFDOxcdi0KvQlGDnbpDZrNm_dDvxraSHKp3WT22pErNXxLJEG19pO PewONW6i9L7lRh81CAhBkb_qbOiz69ieyGd_V4qRSnOvaMM85xqnGi5KZ0B2CN0AHXaAR2mKJaKX .c8vGIRQefGmchsctKe0hwKI5zXddNVtDrBX64wQwthpTJ_lPoEZtbtiFfiotXl025Jn4ZHSUkhJ 56KQYL46PT0FDtZaaVv2kjowTObngC3dWmtsWQshprHSaQTq5hjjRMz1A_f2sb6IqvXVmpYjCu34 kzRJwLEGyutoEaxG6Olk.YKz3UwCrDVn3Ev_0dtXyDQY9tqrEOyK5RzwSm_b_kvg4H9eCeabjHpL ZqqqR678JGsBw.kZvaWkDfcNJmBPDGVKlFejenW4DzronJ0mjZB9bPalWc8BEu050IMYonzkUC0. UlKhwCHPz_iPguGWj_a_ERIvsp_Ao65syMZs7fpsQN2gjY_vxve6bC1_N1WGzIaq8V8FCeDDWNqx ntlOWK4hrEiYTtx06oBR5SKI1F0NKw5CV3pjjEtc63dmnwilcZknKFQGkTMPEkXDi4DClNTzpSar YXGc1AMQlV4wgczjSmZQmJA6zFFaqwlV8si_rG4IIcS9s0HopbbSJzHpSWauR.LC_pOOSE1shJc9 IZ4vOosA_Q1unNA2iFP7qGjzhnArWkE9bGtcya77KaRuvL5Gq5Y5iWRIlTQjtAaonayv0GU84REK zTggWlzWluM0vGugFuHr7p1SP4TJnv3fZM.JNruexINzQ1860XmVzBRtFaPaOUspcWNw2xN9wDap 4DU5yRJ._brtd3gQVCu.uPHoGPGmExJnmbI9SGGgN5TtMRSoVUlN2.LT11LeeVUcUUTSYN3g.AyD vjeZjG4_JD6NUy0CqwcdbLqjNtAvaf6thM4nzS4dhGe6O7IbwjPhNG2dB54NU_p9A5WqiNCJ2S4B rMopeqN46_u9l0qNrApkQEx3GrvzAa9ej1z9fYXEXubGaOZLKv_NaBhVg1T.GyCGUS9y4ctets6z 2nXSHx5yXMgMW0GXseIALFTkbL20efvK2ezCg0O.weTqEFrjo44Q.wbe6zkTXdOeFXHGol.xzjbb TpuDK_GAiIRbmhKIly9Lpy3WEOpwbt8xt3f1xFrgd4w-- X-Sonic-MF: X-Sonic-ID: 41552c7f-72b0-4ab3-804f-4240e766a1c1 Received: from sonic.gate.mail.ne1.yahoo.com by sonic318.consmr.mail.gq1.yahoo.com with HTTP; Tue, 12 Mar 2024 17:18:23 +0000 Date: Tue, 12 Mar 2024 17:18:17 +0000 (UTC) From: Sergey Prokhorenko To: "Andrey M. Borodin" , Jelte Fennema-Nio Cc: Aleksander Alekseev , pgsql-hackers mailing list , Peter Eisentraut , =?UTF-8?Q?Przemys=C5=82aw_Sztoch?= , "David G. Johnston" , Mat Arye , Matthias van de Meent , Nikolay Samokhvalov , Junwang Zhao Message-ID: <1069036712.2624224.1710263897980@mail.yahoo.com> In-Reply-To: References: <0A0D7507-C434-46AC-BCC4-1166C5A2742A@yandex-team.ru> <1459150585.359059.1706132985954@mail.yahoo.com> <00B784AB-5B52-4CC7-8A0D-B1C0C53B52DC@yandex-team.ru> <1014147035.642629.1706202245918@mail.yahoo.com> <5932FFF8-4E5F-44DC-8FEA-22E8302759C7@yandex-team.ru> <8AA22330-7D3A-46CF-B311-2FF874D7C713@yandex-team.ru> <1971811009.2132347.1706599708209@mail.yahoo.com> <72C1E7CB-E2EC-46CF-AD2C-B3180CED885B@yandex-team.ru> <0906F8BA-CA52-4956-AA68-E9193E50DFDF@yandex-team.ru> <10553e4c-6b66-44b9-86a7-80bb1958a767@eisentraut.org> <5D22C2BF-5DED-43CA-A3D7-B724EE0A159D@yandex-team.ru> <844E6A65-4A36-4A36-94C2-0CDF7615B53F@yandex-team.ru> Subject: Re: UUID v7 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2624223_2116417625.1710263897978" X-Mailer: WebService/1.1.22129 YMailNorrin Content-Length: 14293 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------=_Part_2624223_2116417625.1710263897978 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi=C2=A0Jelte, I am one of the contributors to this RFC. Andrey's patch corresponds exactly to Fixed-Length Dedicated Counter Bits (= Method 1). Andrey and you simply did not read the RFC a little further down in the tex= t: __________________________________________________________________ The following sub-topics cover topics related solely with creating reliable= fixed-length dedicated counters: =20 - Fixed-Length Dedicated Counter Seeding: - =20 Implementations utilizing the fixed-length counter method randomly initiali= ze the counter with each new timestamp tick. However, when the timestamp ha= s not increased, the counter is instead incremented by the desired incremen= t logic. When utilizing a randomly seeded counter alongside Method 1, the r= andom value=C2=A0MAY=C2=A0be regenerated with each counter increment withou= t impacting sortability. The downside is that Method 1 is prone to overflow= s if a counter of adequate length is not selected or the random data genera= ted leaves little room for the required number of increments. Implementatio= ns utilizing fixed-length counter method=C2=A0MAY=C2=A0also choose to rando= mly initialize a portion of the counter rather than the entire counter. For= example, a 24 bit counter could have the 23 bits in least-significant, rig= ht-most, position randomly initialized. The remaining most significant, lef= t-most counter bit is initialized as zero for the sole purpose of guarding = against counter rollovers. -=20 - Fixed-Length Dedicated Counter Length: - Select a counter bit-length that can properly handle the level of t= imestamp precision in use. For example, millisecond precision generally req= uires a larger counter than a timestamp with nanosecond precision. General = guidance is that the counter=C2=A0SHOULD=C2=A0be at least 12 bits but no lo= nger than 42 bits. Care must be taken to ensure that the counter length sel= ected leaves room for sufficient entropy in the random portion of the UUID = after the counter. This entropy helps improve the unguessability characteri= stics of UUIDs created within the batch. - The following sub-topics cover rollover handling with either type o= f counter method: =20 - ... -=20 - Counter Rollover Handling: - =20 Counter rollovers=C2=A0MUST=C2=A0be handled by the application to avoid sor= ting issues. The general guidance is that applications that care about abso= lute monotonicity and sortability should freeze the counter and wait for th= e timestamp to advance which ensures monotonicity is not broken. Alternativ= ely, implementations=C2=A0MAY=C2=A0increment the timestamp ahead of the act= ual time and reinitialize the counter. Sergey Prokhorenkosergeyprokhorenko@yahoo.com.au=20 On Tuesday, 12 March 2024 at 06:36:13 pm GMT+3, Jelte Fennema-Nio wrote: =20 =20 On Mon, 11 Mar 2024 at 19:27, Andrey M. Borodin wro= te: > Sorry for this long and vague explanation, if it still seems too uncertai= n we can have a chat or something like that. I don't think this number pick= ing stuff deserve to be commented, because it still is quite close to rando= m. RFC gives us too much freedom of choice. I thought your explanation was quite clear and I agree that this approach makes the most sense. I sent an email to the RFC authors to ask for their feedback with you (Andrey) in the CC, because even though it makes the most sense it does not comply with the either of method 1 or 2 as described in the RFC. =20 ------=_Part_2624223_2116417625.1710263897978 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jelte,
=

Andrey's patch corresponds exactly to Fixed-Length De= dicated Counter Bits (Method 1).

=
= Andrey and you simply did not read the RFC a little further down in t= he text:
________________________________________________= __________________

The following sub-topics cover topics= related solely with creating reliable fixed-length dedicated counters:=

Fixed-Length Dedicated Counter Seeding:

Impl= ementations utilizing the fixed-length counter method randomly initializ= e the counter with each new timestamp tick. However, when the timest= amp has not increased, the counter is instead incremented by the desire= d increment logic. When utilizing a randomly= seeded counter alongside Method 1, the random value MAY&n= bsp;be regenerated with each counter increment without impacting sortabilit= y. The downside is that Method 1 is prone to overflows if a counter of adeq= uate length is not selected or the random data generated leaves little room= for the required number of increments. Impl= ementations utilizing fixed-length counter method MAY also choose to randomly initialize a portion of the co= unter rather than the entire counter. For example, a 24 bit counter could h= ave the 23 bits in least-significant, right-most, position randomly initial= ized. The remaining most significant, left-most counter bit is initializ= ed as zero for the sole purpose of guarding against counter rollovers.<= /font>

Fixed-Length Dedicated Counter Length:<= /dt>
Select a counte= r bit-length that can properly handle the level of timestamp precision in u= se. For example, millisecond precision generally requires a larger counter = than a timestamp with nanosecond precision. = General guidance is that the counter SHOULD be at= least 12 bits but no longer than 42 bits. Care must be taken to ensure that the counter length selected leaves roo= m for sufficient entropy in the random portion of the UUID after the counte= r. This entropy helps improve the unguessability characteristics of UUIDs c= reated within the batch.
The following sub-topics cover rollover handling w= ith either type of counter method:
...
Counter Rollover Handling:<= /dt>

Counter rollovers MUST be handled by t= he application to avoid sorting issues. The general guidance is that applic= ations that care about absolute monotonicity and sortability should freeze = the counter and wait for the timestamp to advance which ensures monotonicit= y is not broken. Alternatively, implement= ations MAY increment the timestamp ahead of the actu= al time and reinitialize the counter.

<= /div>

Sergey Prokhorenko
= sergeyprokhorenko@yahoo.com.au


=20
=20
On Tuesday, 12 March 2024 at 06:36:13 pm GMT+3, Jelte F= ennema-Nio <postgres@jeltef.nl> wrote:


On Mon, 11 Mar 2024 at 19:27, Andrey = M. Borodin <x4mmm@yandex-team.ru> wrote:

> Sorry for this long and vague explanation, if it still seems too = uncertain we can have a chat or something like that. I don't think this num= ber picking stuff deserve to be commented, because it still is quite close = to random. RFC gives us too much freedom of choice.


I thought your explanation was quite clear and I agree = that this
approach makes the most sense. I sent an email = to the RFC authors to
ask for their feedback with you (An= drey) in the CC, because even
though it makes the most se= nse it does not comply with the either of
method 1 or 2 a= s described in the RFC.

------=_Part_2624223_2116417625.1710263897978--