Re: WAL compression setting after PostgreSQL LZ4 default change

On 8/7/26 12:22, Tomas Vondra wrote:
>
>
> On 8/7/26 10:34, Andrey Borodin wrote:
>> Tomas, thanks for benchmarks! I agree that x2 WAL reduction actually makes Zstd
>> a good default when wal_compression = on.
>>
>>> On 7 Aug 2026, at 13:23, Tomas Vondra <tomas(at)vondra(dot)me> wrote:
>>>
>>> 8.25% postgres libzstd.so.1.5.7 [.] ZSTD_createDCtx_internal
>>
>> (sorry for offtopic)
>>
>> That's an interesting profile.
>> Along with published patch to retain compression context we can also
>> retain decompression context. But that's for PG20 anyway.
>>
>
> Right, there may be a way to make the zstd decompression cheaper. But
> it's too late for PG19.
>

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.

On one of them, the recovery timings are roughly this:

lz4 145 sec
zstd 158 sec
zstd+0001 147 sec

The perf profile changes from

19.14% postgres postgres [.] pg_checksum_block_avx2
8.99% postgres libzstd.so.1.5.7 [.] ZSTD_createDCtx_internal
8.13% postgres libzstd.so.1.5.7 [.] ZSTD_decompressSequences_...
5.19% postgres postgres [.] hash_search_with_hash_value
3.28% postgres libzstd.so.1.5.7 [.] HUF_readDTableX1_wksp.con...
3.15% postgres libzstd.so.1.5.7 [.] FSE_decompress_wksp_body_...
3.15% postgres libzstd.so.1.5.7 [.] ZSTD_buildFSETable_body_...
2.37% postgres postgres [.] MarkBufferDirty
2.03% postgres libzstd.so.1.5.7 [.] HUF_readStats_body_bmi2...
1.83% postgres postgres [.] FlushBuffer.constprop.0
1.81% postgres postgres [.] LWLockAttemptLock
1.74% postgres postgres [.] RestoreBlockImage
1.42% postgres libc.so.6 [.] __internal_syscall_cancel

to

20.94% postgres postgres [.] pg_checksum_block_avx2
12.39% postgres libzstd.so.1.5.7 [.] ZSTD_decompressSequences_...
5.49% postgres postgres [.] hash_search_with_hash_value
3.89% postgres libzstd.so.1.5.7 [.] HUF_readDTableX1_wksp....
3.86% postgres libzstd.so.1.5.7 [.] ZSTD_buildFSETable_body_...
3.57% postgres libzstd.so.1.5.7 [.] FSE_decompress_wksp_body_...
2.42% postgres libzstd.so.1.5.7 [.] HUF_readStats_body_bmi2...
2.21% postgres postgres [.] MarkBufferDirty
1.92% postgres postgres [.] LWLockAttemptLock
1.83% postgres postgres [.] RestoreBlockImage
1.67% postgres postgres [.] FlushBuffer.constprop.0
1.63% postgres libc.so.6 [.] __internal_syscall_cancel

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.

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.

regards

[1]
https://www.postgresql.org/message-id/flat/A2BB6471-C150-423C-B6F5-BFEC46BE544B%40yandex-team.ru#8b3c1325d44beb6358e76dda882e7e34

--
Tomas Vondra