Re: Compression of bigger WAL records

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Japin Li <japinli(at)hotmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, wenhui qiu <qiuwenhuifx(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Compression of bigger WAL records
Date: 2026-10-08 06:20:35
Message-ID: 1C553BD4-3958-4692-B648-9C007412B16A@yandex-team.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 8 Oct 2026, at 04:06 UTC, Michael Paquier wrote:
> I was wondering about some micro-benchmarking to
> reduce the amount of noise to zero

Yes, and for the replay results there is one specific thing to isolate:
with DYNAMIC_BMI2, ZSTD_initDCtx_internal() does CPU feature detection
via CPUID for every new context, in both 1.5.5 and 1.5.7 [0]. Context
reuse avoids that as well as palloc/pfree. My benchmark host is a KVM
guest, so I wonder whether the cost of that check contributes to the
difference.

This is still only a hypothesis. My benchmark hosts are unavailable today
due to data center maintenance. When they are back, I can measure context
creation and library versions.

Best regards, Andrey Borodin.

[0] https://github.com/facebook/zstd/blob/v1.5.7/lib/decompress/zstd_decompress.c#L252-L275

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey Borodin 2026-10-08 06:27:01 Re: Snapshot export on a standby corrupts hint bits on subxact overflow
Previous Message Radim Marek 2026-10-08 06:17:10 Re: REPACK (CONCURRENTLY) can't complete after ~105M concurrent updates/deletes