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 <[email protected]> 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
