Re: WAL compression setting after PostgreSQL LZ4 default change

On 8/4/26 09:03, Hannu Krosing wrote:
> On Mon, Aug 3, 2026 at 10:36 PM Tomas Vondra <tomas(at)vondra(dot)me> wrote:
>>
>> On 8/3/26 15:36, Hannu Krosing wrote:
>>> For the CPU usage vs compression ratio discussion, please remember
>>> that for both lz4 and zstd this depends on certain "compression
>>> effort" flags, which we do not expose to customers (we claim we
>>> already choose the best ones for them :) )
>>>
>>
>> I'm not sure we really make such claims.
>
> Yeah, I re-checked and all the claims I remembered were from mailing
> list discussions, not official docs.
>
>> AFAIK we simply use the default
>> compression levels, specified by the lz4/zstd library, and assume the
>> authors picked the right trade offs. I think that's sensible.
>
> It's a bit more complicated than that - we use zstd level 1 while the
> default for the zstd command-line utility is level 3
>
> We should keep this in mind when running any manual compression tests.
>

Are you sure? Because I see xloginsert.c does this:

len = ZSTD_compress(dest, COMPRESS_BUFSIZE, source, orig_len,
ZSTD_CLEVEL_DEFAULT);

and ZSTD_CLEVEL_DEFAULT (=3) is the constant from zstd library. So at
least for WAL we should be using the "normal" compression level.

> My recollection from running some manual tests a year or two ago is
> that on compression side there was a fair bit of overlap in speed
> between lz4 and zstd when looking across many compression levels.
>
> However, lz4 was a clear winner in decompression speeds, being 2-3
> times faster than zstd.
>

Seems plausible.

I'm running some simple tests, to get a better idea how the algorithms
compare. I have no intention to tune the current compression levels.

regards

--
Tomas Vondra