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 1uyUY4-008nGY-Ai for pgsql-hackers@arkaria.postgresql.org; Tue, 16 Sep 2025 12:12:40 +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 1uyUY1-00HUSJ-9j for pgsql-hackers@arkaria.postgresql.org; Tue, 16 Sep 2025 12:12:38 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uyUY0-00HUSB-SK for pgsql-hackers@lists.postgresql.org; Tue, 16 Sep 2025 12:12:37 +0000 Received: from mail-ed1-x52d.google.com ([2a00:1450:4864:20::52d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uyUXz-000ilH-17 for pgsql-hackers@lists.postgresql.org; Tue, 16 Sep 2025 12:12:36 +0000 Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-62f0411577aso6070943a12.1 for ; Tue, 16 Sep 2025 05:12:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1758024749; x=1758629549; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=DojCk7oSXIrGcqj150kbeD3U5MzRB1jq2YabvGoJr88=; b=DQseVQ1VbdeIDWlLdhhiJWAxQ0jsdizGvQbytE1fZIcKsTKHiAZutMbU2yMAC+fvPI RLcf7OFy1K3LWJTnPN+QBgvFJxBpYlTIDD0Ixdjwsb2bW5acCSv+HIscVnBinuacfg5v EwZakCPS++1iLQkmVM7iMGG3zInHTlDbguqZtu4lwfNUpfYQBgq0LBmXeXlYOfTayBqT alNJMXruQwhLte6nhDxAUwl3Jastd4qludwa8ewCgZ3Bxqpk4LWtI7jB7U2uwR93J4qn YtsEou1d7+1XixjucKAseuAQWXldg8sv/GWZu2bZo45v2s6tIsq9p+E7S8RrYrekdGl9 sHZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758024749; x=1758629549; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=DojCk7oSXIrGcqj150kbeD3U5MzRB1jq2YabvGoJr88=; b=Zm9gjK3ebxqrN0lkxXhiSuvx0lD2Z01ImHy++WiJFrtCfuz+NDwtn4pHV8TD7VlovR GkEOkvvcyVe536TBt/4aRgtnw9CaOW2sQ879KTlmmXskjN4DRMv4/LcPI5F7xnDheIy5 eDvBd7iy6rekpH+kek9D3SceZAcPhoIh0LzvV6s3STtco5G0PHy8dn+1lPLcFBPSVVwo zf5Izji1zAhbMflLEayG7pVy6K8mj1uJTgrWSCl5NQ16uNSaE12VHVG2VQMWrre3lpSt YdXZcvxpsA3zj1r1mxLBOZ22Ixd+dNQI7cqArBGVnKmy3/ZcecYiiccNfapbZNS73Sam PEhQ== X-Forwarded-Encrypted: i=1; AJvYcCWWkUpWPB1QAsh6G5dcO0XKD+oUXC2y2ZhuHpQeieFe88KdEG2JzSezOnCY4FzduWxqXJ6wfXyw+gbGhl4P@lists.postgresql.org X-Gm-Message-State: AOJu0YyjYngTQnPen0fUFXQ7kIraIyygQPcJ+/WD6jjDeFTJucL82K+D Bf09p1P9y2oeHj1vb15wmGQNbbw+hIjYLX5O292RpYTEJWvKu6K3CkFy5bASF7WwaItv/fQWopu szXkWhvvqPHX4oDQUWjsXxPB+IFfogrM= X-Gm-Gg: ASbGnctInzuxkkhLvoJUd93pCxF0XnTGFe5erLltq6rGVW1k9ZUcFDrlSH5lQ5ET2J5 gUJD922CwmZJtxgZMdfhaYyMg/FYvROFE40w38+CseyDEr3Q7/M/lIU+PcfXTzB/af98i1WYjOS NzsUgSmIe49xNwmDdNumSjavIGqs1SWnT/ZNVMn8+FyAhFLebYMLvHRNRmcd49V+eDrFpuhKkjc 6KLAg== X-Google-Smtp-Source: AGHT+IEB9JUws6+RHiKAjQkVPVY522Yw3aXNz0b6iMc03px/4xQrYMYH0zFrO9OM9t1+S5cOH+Q4Km0jLaA9H5Ewrp0= X-Received: by 2002:a05:6402:518f:b0:62f:3436:a396 with SMTP id 4fb4d7f45d1cf-62f3436a5e2mr7969649a12.31.1758024749107; Tue, 16 Sep 2025 05:12:29 -0700 (PDT) MIME-Version: 1.0 References: <4535f3aa-3220-4760-b1f5-2bc91f248e03@iki.fi> <2bc58592-9d74-4af0-bdd1-1a88e8683f7c@iki.fi> <36531c0e-292c-409d-bbc7-a252cf6e910a@iki.fi> In-Reply-To: From: wenhui qiu Date: Tue, 16 Sep 2025 20:12:17 +0800 X-Gm-Features: AS18NWBrZ5oNMQb6iUwSHlwpHE4N5jfOsWoSIZIJB0RVW0DQQ2A-JyWcfQOS9p8 Message-ID: Subject: Re: POC: make mxidoff 64 bits To: Maxim Orlov Cc: Alexander Korotkov , Ashutosh Bapat , Heikki Linnakangas , Postgres hackers Content-Type: multipart/alternative; boundary="000000000000ad4f5d063eea0894" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000ad4f5d063eea0894 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Maxim Thanks for your continued efforts to get XID64 implemented. > 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. Agree +1 , but I have a question: I remember the XID64 patch got split into a few threads. How are these threads related? The original one was seen as too big a change, so it was broken up after people raised concerns. Thanks On Mon, Sep 15, 2025 at 11:42=E2=80=AFPM Maxim Orlov wr= ote: > > > On Sat, 13 Sept 2025 at 16:34, Alexander Korotkov > 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. > --000000000000ad4f5d063eea0894 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Maxim
=C2=A0 Thanks for you= r continued efforts to get XID64 implemented.=C2=A0=C2=A0
>=C2=A0=C2= =A0 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 a= lways=C2=A0
> fit uint32.

> It=C2= =A0appears=C2=A0logical to me.
Agree=C2=A0+1 , but I have a question: I = remember the XID64 patch got split into a few threads. How are these thread= s related? The original one was seen as too big a change, so it was broken = up after people raised concerns. =C2=A0

Thanks

=
On Mon, Se= p 15, 2025 at 11:42=E2=80=AFPM Maxim Orlov <orlovmg@gmail.com> wrote:


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

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).=C2=A0 The actual multixact offsets can be calculated at the fly, overhead shouldn't be significant.=C2=A0 What do you think?

Thank you for your review; I'm pl= eased to hear from you again.

Yes, because the maximum number of mxo= ff 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 "ba= se".

I believe we may take advantage of the 64XID patch's n= otion of putting a=C2=A0
8 byte base followed by 4 byte offsets f= or particular page.=C2=A0

32kB page may contain th= en 2^13-2 offsets, each is maxed by 2^18+1.
Therefore, offset fro= m base will never overflow 2^31 and will always=C2=A0
fit=20 uint32.

It=C2=A0appears=C2=A0logical to me.
<= /div>


--
Best regards,
Maxim Orlov.
--000000000000ad4f5d063eea0894--