Re: WAL compression setting after PostgreSQL LZ4 default change

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tomas Vondra <tomas(at)vondra(dot)me>
Cc: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Ken Marshall <ktm(at)rice(dot)edu>, Hannu Krosing <hannuk(at)google(dot)com>, Andreas Karlsson <andreas(at)proxel(dot)se>, Christoph Berg <myon(at)debian(dot)org>, wenhui qiu <qiuwenhuifx(at)gmail(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Andres Freund <andres(at)anarazel(dot)de>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Japin Li <japinli(at)hotmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, John Naylor <johncnaylorls(at)gmail(dot)com>
Subject: Re: WAL compression setting after PostgreSQL LZ4 default change
Date: 2026-08-07 22:25:26
Message-ID: anZbVWCy-pOqWboY@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 07, 2026 at 10:09:46PM +0200, Tomas Vondra wrote:
> FWIW I've tried with the 0001 part from the patch series in [1], which
> reuses the zstd decompression context, and that significantly reduces
> the difference between lz4 and zstd on the azure instances.
>
> i.e. ZSTD_createDCtx_internal disappears, which is ~9% of CPU time.
>
> I take this as a confirmation that most of the difference is indeed due
> to the lower decompression speed.

Oh. We should definitely try something like that for v20. That makes
sense for continuously decompressing sets of 8k pages. And the CCtx
seems to be supported for quite some time (minimum version we require
is 1.4, that has the CCtx things). Nice.

> The question is what does this mean for this thread, i.e. for the
> question what should 'on' translate to. I still think zstd seems like a
> better default, despite this one result where lz4 does a bit better.
> Especially if we know it the difference can be mostly eliminated.

Thanks for all the benchmarks. Picking up a good default is hard,
still I'd keep zstd as a better default choice overall, even after
seeing these numbers.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sami Imseih 2026-08-07 22:45:11 Re: Remove unused vacuum-truncate-auto injection point
Previous Message Dhruv Aron 2026-08-07 22:14:05 Re: Restructured Shared Buffer Hash Table