Re: POC: make mxidoff 64 bits

From: Maxim Orlov <orlovmg(at)gmail(dot)com>
To: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
Cc: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, wenhui qiu <qiuwenhuifx(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: POC: make mxidoff 64 bits
Date: 2025-09-15 15:42:00
Message-ID: CACG=ezaCc4bFfua-VA1NB6wppMPwuMmZiGdrkb-iYK9ZmQa6gg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, 13 Sept 2025 at 16:34, Alexander Korotkov <aekorotkov(at)gmail(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-09-15 16:15:26 Re: BUG #18959: Name collisions of expression indexes during parallel Index creations on a pratitioned table.
Previous Message Emmanuel Sibi 2025-09-15 15:19:01 Re: [BUG] PostgreSQL crashes with ThreadSanitizer during early initialization