Message-ID: <52227f05-51aa-40c4-8f83-9c79fff16175@iki.fi>
Date: Tue, 2 Dec 2025 16:47:29 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: POC: make mxidoff 64 bits
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>
References: 
 <CACG=ezaWg7_nt-8ey4aKv2w9LcuLthHknwCawmBgEeTnJrJTcw@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>
 <54aa8f65-f0e4-4464-b543-e0399c1cab1e@iki.fi>
 <CACG=ezYUJSvnuxntkURNWo_1vZ+AtmcQfqd_h6WgDzGaudfw+Q@mail.gmail.com>
 <4a9dda70-0af7-41a4-9636-b168f2fc48ef@iki.fi>
 <46cc45e9-fddd-44bc-bcb3-96889aafd921@iki.fi>
 <CAExHW5tUEkiQrvm9hgccjKUNkWBnJ5_HDUrAwiHBTxu+Vuj29Q@mail.gmail.com>
 <6c298bc4-7029-4c1d-bf16-3e094842ce32@iki.fi>
 <9ee6324a-44fc-42fb-bf8e-7c3b53395588@iki.fi>
 <CAPpHfdsMd9TQ8ZbMnStMfFvBoBMwBCSC+8zcOYY9VDMYQzUYyQ@mail.gmail.com>
Content-Language: en-US
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: 
 <CAPpHfdsMd9TQ8ZbMnStMfFvBoBMwBCSC+8zcOYY9VDMYQzUYyQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/52227f05-51aa-40c4-8f83-9c79fff16175%40iki.fi>
Precedence: bulk

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