Re: Compress prune/freeze records with Delta Frame of Reference algorithm

From: Evgeny Voropaev <evgeny(dot)voropaev(at)tantorlabs(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
Subject: Re: Compress prune/freeze records with Delta Frame of Reference algorithm
Date: 2026-03-24 14:28:24
Message-ID: e4d4fef2-165c-4d27-8366-18cfef5d6484@tantorlabs.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello Andres,

> 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?

So far, we have had no tests in any real production environment.
Moreover, the load in the new test
(recovery/t/052_prune_dfor_compression.pl) is quite contrived. However,
it demonstrates a compression ratio of more than 5, and it is measured
for an overall size of all prune/freeze records with no filtering.

Further development is the implementation of compression of unsorted
sequences. This is going to allow PostgreSQL to compress also the
'frozen' and the 'redirected' offset sequences, which should result in a
greater compression ratio.

But I agree with you, Andres, we need practical results to estimate a
profit. I wish we would test it on some real load soon.

Also I hope, independently of its usage in prune/freeze records, the
DFoR itself might be used for compression sequences in other places of PG.

Best regards,
Evgeny Voropaev.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Lukas Fittl 2026-03-24 14:28:42 Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
Previous Message Jelte Fennema-Nio 2026-03-24 14:27:31 Re: Add GoAway protocol message for graceful but fast server shutdown/switchover