Re: Compression of bigger WAL records

On Wed, Oct 07, 2026 at 09:42:42PM +0500, Andrey Borodin wrote:
> I found the original logs: 4.34 and 4.14 seconds without the patch and
> 2.32 and 2.33 with it. lz4 was just an unchanged control: 1.59 seconds in
> all four runs. The 200MB figure was compressed WAL, not raw page images.
> I have not remeasured these numbers on v10.

Thanks. I don't expect a difference as on replay we use a single
xlogreader, meaning one callback across the board.

Averaging 4 runs across multiple environments, I get:
- 1.76s for HEAD vs 1.72s for the patch on one machine, 6M rows
(EC2 on Debian with libzstd at 1.5.7), or ~2.3%.
- 2.52s for HEAD vs 2.44s for the patch on a second machine, 6M rows
(laptop, Fedora 44 with libzstd again at 1.5.7) or ~3.2%.
- 2.62s for HEAD vs 2.57s for the patch on a third machine, 12M rows
(bigger box, Fedora 44, 1.5.7) or ~1.9%.

So these numbers are matching my first impressions, and I am compiling
with a -O2, no asserts, etc. I have repeated the same test with your
v8, in case I was missing something, and my numbers with v8 still
match with v10.

> Tomas also tested context reuse in the wal_compression default thread
> [0]: recovery went from 158 to 147 seconds, versus 145 with lz4.
> ZSTD_createDCtx_internal disappeared from the profile, where it had
> accounted for about 9% of sampled CPU time.

I think that this just points out to the fact that my benchmarking
skills deeply suck compared to Tomas's, but I'm still able to see wins
anyway in all the places where I am comparing HEAD vs the patch.
Applied the recovery part.
--
Michael