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

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Evgeny Voropaev <evgeny(dot)voropaev(at)tantorlabs(dot)com>, Tomas Vondra <tomas(at)vondra(dot)me>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Compress prune/freeze records with Delta Frame of Reference algorithm
Date: 2026-04-09 17:55:01
Message-ID: 9381130C-B961-4DAF-B950-E4ABFCE4CCA0@yandex-team.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 9 Apr 2026, at 21:50, Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> These numbers make the impact sound bigger than I think it really is:
>
> - They neglect that the insert generates ~183MB of WAL, the delete ~161MB
> without indexes and ~243MB / 161MB with. In contrast to that 6.7Mb isn't
> particularly significant.

Well, vacuuming of a bloated tables does happen. The amount of WAL needed to
accumulate bloat does not invalidate benefits of reducing WAL needed to vacuum
bloat.

> - Workloads deleting almost all records in the table but leaving some in to
> prevent truncation aren't particularly common.

Queue tables may be kind of antipattern, yet users use such tables. And sometimes
they tend to have ~90% bloat. And cause 99% of problems.

> - The narrowness of the rows (~30 bytes, with row header) makes the wins much
> bigger than they'd be in realistic cases

It’s crafted benchmark to demonstrate bright side. It’s also super easy to demonstrate
the case when proposed patch does not give any benefit at all.

Evgeny, do you know of any cases when the patch has negative effect?

I think if it’s strictly non-negative - then we can just weight complexity of maintaining
the proposed approach against benefits.

> - The workload doesn't involve any FPIs. It's much more common to have
> vacuum's occur later and trigger FPIs.

AFAIU, without special handling FPIs will not substitute xl_heap_prune, will they?

> Heh. In this case FPIs actually would *reduce* the overhead of the current
> code, because the page is so empty after all the deletes that the FPI uses
> less space than the update . It's 4.1MB when not using indexes and not using
> wal compression and 1MB with wal compression.
>
> Seems we could get a fair bit of benefit by just using a heuristic to switch
> to an FPI when there are enough changes.

I think we could even do it in a generic way: if the record body is heavier that its FPIs - just
do FPIs only.

Best regards, Andrey Borodin.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Lakhin 2026-04-09 18:00:00 Re: test_autovacuum/001_parallel_autovacuum is broken
Previous Message Jim Jones 2026-04-09 17:46:02 Re: Fix bug with accessing to temporary tables of other sessions