Re: WAL compression setting after PostgreSQL LZ4 default change - Mailing list pgsql-hackers

From wenhui qiu
Subject Re: WAL compression setting after PostgreSQL LZ4 default change
Date
Msg-id CAGjGUAJaGmTwSSiF2so69Pjmjo4zwhsA+dmcUGRmqM856K9pBA@mail.gmail.com
Whole thread
In response to Re: WAL compression setting after PostgreSQL LZ4 default change  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Hi Michael



> If I were switch the default, for me zstd goes first, lz4 is a close
> second, and pglz is the last of its class.  The only reason why we
> have not chosen zstd for TOAST is the fact that we don't support it
> (trickier to add support for it as we have to preserve on-disk
> compatibility for inline compressed TOAST entries).

> In short, lz4 is available in many environments, but I'm also ready to
> bet that zstd is equally available in these environments.
Thanks for the feedback.

Yes, I did consider zstd as well. I agree that zstd can provide a better
compression ratio than lz4, and if we only look at compression ratio, zstd is
a very attractive choice.

The reason I started with lz4 was mainly to keep this change aligned with the
recent TOAST compression change. Since lz4 has already been accepted there as
the preferred default when available, I thought using the same choice for
wal_compression=on would make the proposal smaller, more consistent, and easier
to evaluate. so

Second, WAL compression happens on the WAL insertion path for full-page images,
so compression speed and CPU overhead matter a lot. lz4 is generally a good fit
for that trade-off: it still reduces WAL volume, while keeping compression
latency and CPU cost lower than zstd in many workloads.

That said, I understand the argument for preferring zstd when it is available.
I have prepared an alternative version where wal_compression=on selects zstd
first, then lz4 if zstd is not available, and finally pglz as the fallback

Thanks 
Attachment

pgsql-hackers by date:

Previous
From: Xuneng Zhou
Date:
Subject: Re: Update EnableTimeoutParams timeout type comment
Next
From: Chao Li
Date:
Subject: Re: Fix Grammar in Buffer Lock Wait Message