Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.500.181\))
Subject: Re: Compress prune/freeze records with Delta Frame of Reference
 algorithm
From: Andrey Borodin <x4mmm@yandex-team.ru>
In-Reply-To: <d4gecdvma2s36vy3chrzjhvd5lwxjvff7yecgpqo5zd5nsgv24@w3jt7z62xrgh>
Date: Thu, 9 Apr 2026 22:55:01 +0500
Cc: Evgeny Voropaev <evgeny.voropaev@tantorlabs.com>,
 Tomas Vondra <tomas@vondra.me>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9381130C-B961-4DAF-B950-E4ABFCE4CCA0@yandex-team.ru>
References: <acf7e923-7ad6-42ed-b16a-df15e876d249@tantorlabs.com>
 <wps75qdtwpykdt4zatfh2u2hi3zju4drdzqi2zh7uy3x4ooivv@kc2fxfz7lx3e>
 <e4d4fef2-165c-4d27-8366-18cfef5d6484@tantorlabs.com>
 <5a2f3df2-a736-4ada-8aa3-aa6e20b2e067@vondra.me>
 <3fc9f40b-2c4f-49c7-bf1c-570c5b9e6e9e@tantorlabs.com>
 <d4gecdvma2s36vy3chrzjhvd5lwxjvff7yecgpqo5zd5nsgv24@w3jt7z62xrgh>
To: Andres Freund <andres@anarazel.de>
Archived-At: 
 <https://www.postgresql.org/message-id/9381130C-B961-4DAF-B950-E4ABFCE4CCA0%40yandex-team.ru>
Precedence: bulk


> On 9 Apr 2026, at 21:50, Andres Freund <andres@anarazel.de> wrote:
>=20
> These numbers make the impact sound bigger than I think it really is:
>=20
> - 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=E2=80=99s crafted benchmark to demonstrate bright side. It=E2=80=99s =
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=E2=80=99s 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.
>=20
>  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.=