MIME-Version: 1.0
References: 
 <CACG=ezaWg7_nt-8ey4aKv2w9LcuLthHknwCawmBgEeTnJrJTcw@mail.gmail.com>
 <CACG=ezYtCatcRODS-ZkwhcxuqBKCuhEsZGBruw=dGCLoepF+ZA@mail.gmail.com>
 <ca451a6a-5b0f-433c-8ab9-b28b7f480bd7@iki.fi>
 <CACG=ezb680eb=JXh1ns=t5eGH3h9y-uTfT4tf3Xc8t2UH2q6tQ@mail.gmail.com>
 <CACG=ezZGQFBb0yepka8hU2BmJ48ujt3xa+aYLNL0BQPx0vqwZg@mail.gmail.com>
 <CACG=ezajc_Pcqmy6fcq-N8+LzCRMzOzJzez2_BgHEu-6RVJtKQ@mail.gmail.com>
 <4535f3aa-3220-4760-b1f5-2bc91f248e03@iki.fi>
 <CACG=ezbKwypBp=14q9+hMQApus3=1hKxJ9x1+KinUhtT48570Q@mail.gmail.com>
 <2bc58592-9d74-4af0-bdd1-1a88e8683f7c@iki.fi>
 <CACG=ezZwdvsijzuXE3hex3xHcoz75EQYBXRTsQJVwbo5J5sS3g@mail.gmail.com>
 <CACG=ezbs912S58=uR17b4w8uuWv1=OcCRaTW_OWdFm4+tXZA6w@mail.gmail.com>
 <CAGjGUA+BfcWyccNN4=tHsW_E-koRxbg8h8ut6hjvPsHMgmek6w@mail.gmail.com>
 <CACG=ezYbYO_KHWdeDedbDcY0tOS0JfaqBxG3=bG5+DdsDK4MpQ@mail.gmail.com>
 <CACG=ezYpZRPwoRCz_h3Qerd3XJNdpTHCpwGbZphNdy26tA4_qQ@mail.gmail.com>
 <36531c0e-292c-409d-bbc7-a252cf6e910a@iki.fi>
 <e9507fef-da9a-4fe4-9fe1-5de2d7446547@iki.fi>
 <CAGjGUAK1Cpa5Sm0cJVX7iG-uKXpNC26BjWq8yJS40ZpCdenC4g@mail.gmail.com>
 <CACG=ezYiLzCSo43uTPzAeq8ZCnGSkAsw061=oMyw5J1NUZ9Jwg@mail.gmail.com>
 <CAExHW5soKc9mhLhroi__yrPD-ymkFbz=e5hyZ34iqjM-cdK9_g@mail.gmail.com>
 <CACG=ezaLdhpFY9_qr7B6s7kkg_=s5S_ZD2=dsSeBNgdWWWuKbg@mail.gmail.com>
 <CACG=ezaFoCx4XEGi4gQWrusYD81LTLTKBUdgs-mEjNwzVarRnw@mail.gmail.com>
 <CACG=ezarNdLaTdr3fdWGyVJEzRAa=Vd5LLmu7VN2r7XL6LH8xA@mail.gmail.com>
 <CAPpHfdtPybyMYBj-x3-Z5=4bj_vhYk2R0nezfy=Vjcz4QBMDgw@mail.gmail.com>
In-Reply-To: 
 <CAPpHfdtPybyMYBj-x3-Z5=4bj_vhYk2R0nezfy=Vjcz4QBMDgw@mail.gmail.com>
From: Maxim Orlov <orlovmg@gmail.com>
Date: Mon, 15 Sep 2025 18:42:00 +0300
Message-ID: 
 <CACG=ezaCc4bFfua-VA1NB6wppMPwuMmZiGdrkb-iYK9ZmQa6gg@mail.gmail.com>
Subject: Re: POC: make mxidoff 64 bits
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
 wenhui qiu <qiuwenhuifx@gmail.com>,
	Heikki Linnakangas <hlinnaka@iki.fi>,
 Postgres hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000000175ef063ed8d933"
Archived-At: 
 <https://www.postgresql.org/message-id/CACG%3DezaCc4bFfua-VA1NB6wppMPwuMmZiGdrkb-iYK9ZmQa6gg%40mail.gmail.com>
Precedence: bulk

--0000000000000175ef063ed8d933
Content-Type: text/plain; charset="UTF-8"

On Sat, 13 Sept 2025 at 16:34, Alexander Korotkov <aekorotkov@gmail.com>
wrote:

>
> Therefore, we can change from each 8 of 32-bit multixact offsets
> (takes 32-bytes) to one 64-bit offset + 7 of 24-bit offset increments
> (takes 29-bytes).  The actual multixact offsets can be calculated at
> the fly, overhead shouldn't be significant.  What do you think?
>
>
Thank you for your review; I'm pleased to hear from you again.

Yes, because the maximum number of mxoff is limited by the number of
running transactions, we may do it that way.
However, it is a bit wired to have offsets with the 7-byte "base".

I believe we may take advantage of the 64XID patch's notion of putting a
8 byte base followed by 4 byte offsets for particular page.

32kB page may contain then 2^13-2 offsets, each is maxed by 2^18+1.
Therefore, offset from base will never overflow 2^31 and will always
fit uint32.

It appears logical to me.


-- 
Best regards,
Maxim Orlov.

--0000000000000175ef063ed8d933
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, 13 Sept=
 2025 at 16:34, Alexander Korotkov &lt;<a href=3D"mailto:aekorotkov@gmail.c=
om">aekorotkov@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex"><br>
Therefore, we can change from each 8 of 32-bit multixact offsets<br>
(takes 32-bytes) to one 64-bit offset + 7 of 24-bit offset increments<br>
(takes 29-bytes).=C2=A0 The actual multixact offsets can be calculated at<b=
r>
the fly, overhead shouldn&#39;t be significant.=C2=A0 What do you think?<br=
><br></blockquote><div><br></div><div>Thank you for your review; I&#39;m pl=
eased to hear from you again.<br><br>Yes, because the maximum number of mxo=
ff is limited by the number of <br>running transactions, we may do it that =
way.<br>However, it is a bit wired to have offsets with the 7-byte &quot;ba=
se&quot;.<br><br>I believe we may take advantage of the 64XID patch&#39;s n=
otion of putting a=C2=A0</div><div>8 byte base followed by 4 byte offsets f=
or particular page.=C2=A0</div><div><br></div><div>32kB page may contain th=
en 2^13-2 offsets, each is maxed by 2^18+1.</div><div>Therefore, offset fro=
m base will never overflow 2^31 and will always=C2=A0</div><div>fit=20
uint32.</div><div><br></div><div>It=C2=A0appears=C2=A0logical to me.</div><=
/div><div><br clear=3D"all"></div><br><span class=3D"gmail_signature_prefix=
">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr"=
><div>Best regards,<br></div><div>Maxim Orlov.</div></div></div></div>

--0000000000000175ef063ed8d933--