public inbox for [email protected]  

help / color / mirror / Atom feed

From: Andrey Borodin <[email protected]>
To: Andres Freund <[email protected]>
Cc: Evgeny Voropaev <[email protected]>
Cc: Tomas Vondra <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Compress prune/freeze records with Delta Frame of Reference algorithm
Date: Thu, 9 Apr 2026 22:55:01 +0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <d4gecdvma2s36vy3chrzjhvd5lwxjvff7yecgpqo5zd5nsgv24@w3jt7z62xrgh>
References: <[email protected]>
	<wps75qdtwpykdt4zatfh2u2hi3zju4drdzqi2zh7uy3x4ooivv@kc2fxfz7lx3e>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<d4gecdvma2s36vy3chrzjhvd5lwxjvff7yecgpqo5zd5nsgv24@w3jt7z62xrgh>



> On 9 Apr 2026, at 21:50, Andres Freund <[email protected]> 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.

view thread (17+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Compress prune/freeze records with Delta Frame of Reference algorithm
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox