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
