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.
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 |