Horton

Re: POC: make mxidoff 64 bits

Heikki Linnakangas <hlinnaka@iki.fi>

View thread
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Maxim Orlov <orlovmg@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, wenhui qiu <qiuwenhuifx@gmail.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Date: 2025-12-02T14:47:29Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix partial read handling in pg_upgrade's multixact conversion

  2. Increase timeout in multixid_conversion upgrade test

  3. Improve sanity checks on multixid members length

  4. Clarify comment on multixid offset wraparound check

  5. Never store 0 as the nextMXact

  6. Add runtime checks for bogus multixact offsets

  7. Widen MultiXactOffset to 64 bits

  8. Move pg_multixact SLRU page format definitions to a separate header

  9. Convert confusing macros in multixact.c to static inline functions

  10. Index SLRUs by 64-bit integers rather than by 32-bit integers

  11. Cope with possible failure of the oldest MultiXact to exist.

On 02/12/2025 16:11, Alexander Korotkov wrote:
> I'd like to raise the question about compression again.  You have
> fairly criticized non-deterministic compression, but what do you think
> about deterministic one that I've proposed [1].  I understand that
> multixact offsets are subject of growth and their limit is not
> removed.  However, it's still several extra gigabytes for multixact
> offsets, which we could save.

It felt overly complicated to my taste. And decoding/encoding the whole 
chunk on every access seems expensive. Maybe it's cheap enough that it 
doesn't matter in practice, but some performance testing would at least 
be in order. But I'd love to find a simpler scheme to begin with.

Storing one "base" offset per page, as Maxim did in [1], feels about 
right to me. Except for the non-deterministic nature of how it gets set 
in that patch, and what I referred to as a "frighteningly clever 
encoding scheme".

Perhaps we could set the base offset in ExtendMultiXactOffset() already?

[1] 
https://www.postgresql.org/message-id/CACG%3DezbPUASDL1eJ%2Bc-ZkJMwRPukvp3EL0q1vSUa1h%2BfnX8y3g%40mail.gmail.com

- Heikki