Re: WAL compression setting after PostgreSQL LZ4 default change

On 8/6/26 16:50, Ken Marshall wrote:
> On Thu, Aug 06, 2026 at 04:31:44PM +0200, Hannu Krosing wrote:
>> On Thu, Aug 6, 2026 at 2:11 PM Tomas Vondra <tomas(at)vondra(dot)me> wrote:
>>>
>>> The executive summary is that lz4/zstd perform about the same, but zstd
>>> has a clearly better compression ratio. I withdraw my initial plan to
>>> default to lz4, and I agree we should default to zstd. (By "default" I
>>> mean that "on" would use that algorithm, but the GUC would still default
>>> to 'off' as before. Maybe we should reconsinder that for PG20, though?)
>>
>> Do you have any ideas why recovery on Azure is 10-20% faster for lz4
>> (and surprisingly also pglz) than for zstd ?
>>

I don't, but I'll do a couple more runs with for these parameters
(zstd/3, lz4/1 and pglz), to see how stable the results are.

Might be interesting to run this on other cloud instances, but I don't
have access to those at the moment.

Could this be due to difference in decompression speed? I've seen
figures like 2GB/s for zstd vs. 4GB/s for lz4. We're we'd dealing with
~45GB of WAL, so that'd be 25 vs. 10 seconds, which is not far from the
~20s difference in recovery time. Then again, it only affects azure, so
there's some hw influence.

>> ---
>> Hannu
>
> Hi,
>
> I know that lz4 has much higher decompression speed but I have no idea
> why it would also be faster for pglz. Do they actually use it or call
> lz4 under the hood?
>

I don't understand what this means by "calling lz4 under the hood".

> My two cents is that since cloud CPU is much more expensive than cloud
> storage we should pick the option that minimizes it. In the application
> that I used, it was mostly to pull historic data so the key performance
> metric was rapid decompression speed. It was the difference between a
> sub-second screen draw and not. I would tend to lz4 even with the better
> compression ratio from zstd.
>

Even on the two azure systems, the tests still use local NVMe disks, not
the cloud storage. But I agree that with cloud storage, it's likely
better to prefer higher compression ratio, even if it costs a bit more
CPU (but the difference in CPU usage seem tiny).

FWIW this only affects recovery/replication, not interactive tasks.

regards

--
Tomas Vondra