| From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
|---|---|
| To: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
| Cc: | Maxim Orlov <orlovmg(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, wenhui qiu <qiuwenhuifx(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
| Subject: | Re: POC: make mxidoff 64 bits |
| Date: | 2025-12-02 14:47:29 |
| Message-ID: | 52227f05-51aa-40c4-8f83-9c79fff16175@iki.fi |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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?
- Heikki
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2025-12-02 14:59:55 | Re: Allow GUC settings in CREATE SUBSCRIPTION CONNECTION to take effect |
| Previous Message | Bertrand Drouvot | 2025-12-02 14:43:25 | Fix PrivateRefCount hash table key size |