| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | wenhui qiu <qiuwenhuifx(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Japin Li <japinli(at)hotmail(dot)com>, John Naylor <johncnaylorls(at)gmail(dot)com>, Christoph Berg <myon(at)debian(dot)org> |
| Subject: | Re: WAL compression setting after PostgreSQL LZ4 default change |
| Date: | 2026-06-30 23:45:17 |
| Message-ID: | akRVDdkH1ntCpTBv@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jun 30, 2026 at 06:25:09PM +0800, wenhui qiu wrote:
> The recent PostgreSQL commit changes the default TOAST compression to lz4
> when LZ4 support is available, based on the rationale that LZ4 is generally
> more efficient than pglz in terms of CPU usage and compression
> ratio. Given that, should we also consider changing the default
> compression method used by wal_compression = on from pglz to lz4?
"on" is just a backward-compatible value, so we could let it as-is.
> Currently, wal_compression = on still maps to pglz, while lz4 has to be
> selected explicitly with:
>
> wal_compression = lz4
> If LZ4 is now considered stable and preferable enough to become the default
> for TOAST compression, it may be worth aligning WAL compression behavior as
> well, or at least discussing whether on should continue to imply pglz.
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.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2026-06-30 23:48:07 | Re: Remove radius from initdb authentication methods |
| Previous Message | Michael Paquier | 2026-06-30 23:35:12 | Re: Handle concurrent drop when doing whole database vacuum |