Feedback-ID: id4a34324:Fastmail
Date: Sun, 22 Mar 2026 12:20:25 -0400
From: Andres Freund <andres@anarazel.de>
To: Evgeny Voropaev <evgeny.voropaev@tantorlabs.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Compress prune/freeze records with Delta Frame of Reference
 algorithm
Message-ID: <wps75qdtwpykdt4zatfh2u2hi3zju4drdzqi2zh7uy3x4ooivv@kc2fxfz7lx3e>
References: <acf7e923-7ad6-42ed-b16a-df15e876d249@tantorlabs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <acf7e923-7ad6-42ed-b16a-df15e876d249@tantorlabs.com>
Archived-At: 
 <https://www.postgresql.org/message-id/wps75qdtwpykdt4zatfh2u2hi3zju4drdzqi2zh7uy3x4ooivv%40kc2fxfz7lx3e>
Precedence: bulk

Hi,

On 2026-03-07 21:56:18 +0800, Evgeny Voropaev wrote:
> A prune/freeze record contains four sequences of integers representing
> frozen, redirected, unused, and dead tuples. Currently, these
> sequences are uncompressed, which adds overhead. Eliminating empty
> leading bits in these offsets can reduce the size of the record, and
> applying bit-packing algorithms can reduce it even further. Reducing
> WAL record size also lessens the load on disk and network, which are
> heavily used for storing WAL and transmitting it to replicas. For
> example, with BLCKSZ equal to 8192, the maximum tuple offset is around
> 580. Despite this, all offsets are stored as 16-bit integers with no
> compression applied.

I'm unconvinced that this is a serious problem - typically the overhead of WAL
volume due to pruning / freezing is due to the full page images emitted, not
the raw size of the records. Once an FPI is emitted, this doesn't matter.

What gains have you measured in somewhat realistic workloads?

Greetings,

Andres Freund