Subject: WAL compression setting after PostgreSQL LZ4 default change

From: wenhui qiu <[email-masked]>
Date: Tue, 30 Jun 2026 18:25:09 +0800

HI

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?

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.

Thanks

---

From: Christoph Berg <[email-masked]>
Date: Tue, 30 Jun 2026 12:51:13 +0200

Re: wenhui qiu
> by wal_compression = on from pglz to lz4?

+1 from me. I would prefer this patch over the doc-only one that I
sent in the other thread.

This should go into PG19 so we don't have two different versions that
flip the default from pglz to lz4.

Christoph

---

From: Japin Li <[email-masked]>
Date: Tue, 30 Jun 2026 21:48:50 +0800

> flip the default from pglz to lz4.

+1.  LGTM.

-- 
Regards,
Japin Li
ChengDu WenWu Information Technology Co., Ltd.

---

From: Michael Paquier <[email-masked]>
Date: Wed, 1 Jul 2026 08:45:17 +0900

On Tue, Jun 30, 2026 at 06:25:09PM +0800, wenhui qiu wrote:
> 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.

> 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: wenhui qiu <[email-masked]>
Date: Wed, 1 Jul 2026 09:53:36 +0800

Hi Michael

> 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

---

From: Japin Li <[email-masked]>
Date: Fri, 03 Jul 2026 10:18:08 +0800

On Wed, 01 Jul 2026 at 09:53, wenhui qiu <[email-masked]> wrote:
>  compression ratio than lz4, and if we only look at compression ratio, zstd is
>  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
>  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
>  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

Thanks for updating the patch. I've registered it in the CommitFest [1].

[1] https://commitfest.postgresql.org/patch/6979/

---

From: Fujii Masao <[email-masked]>
Date: Fri, 3 Jul 2026 11:58:52 +0900

> "on" is just a backward-compatible value, so we could let it as-is.

Yes, so +1 to leaving "on" as it is. Making its meaning depend on
the build options seems very confusing. Users who want lz4 or zstd
can simply specify those methods explicitly instead of using "on".

Regards,

-- 
Fujii Masao

---

From: Japin Li <[email-masked]>
Date: Fri, 03 Jul 2026 16:38:06 +0800

> can simply specify those methods explicitly instead of using "on".

Understood.  I'll withdraw this from the CommitFest.

---

From: Michael Paquier <[email-masked]>
Date: Wed, 8 Jul 2026 07:26:34 +0900

> Understood.  I'll withdraw this from the CommitFest.

I disagree.  The whole argument is that most users don't bother
changing the defaults.  Here, a change between lz4/zstd and pglz is
like day and night; folks are going to see improvements all the time
if we switch to a better default when we can, in terms of CPU, memory
and IO.
--
Michael

---

From: Jelte Fennema-Nio <[email-masked]>
Date: Wed, 8 Jul 2026 00:46:53 +0200

> if we switch to a better default when we can, in terms of CPU, memory

A small correction though: "on" isn't the default. The default is
"off". So this would only impact users who changed the setting in
their cluster to "on" at some point in the past when lz4/zstd support
did not exist yet. So we wouldn't be changing the default. We'd be
changing the behavior for people who changed their default setting at
some point.

To be clear, I agree with you that that's a reasonable thing to do; I
don't think any of those people actually want to burn CPU for no
reason. So they'd all be happy if we stopped doing that. pglz
basically has no right to be used anywhere in production systems IMO.

---

From: Christoph Berg <[email-masked]>
Date: Wed, 8 Jul 2026 00:58:59 +0200

Re: Jelte Fennema-Nio
> changing the behavior for people who changed their default setting at

If someone just wants compression and not bother with the ugly details
of compression algorithms, they might be inclined to just say "on".
By labelling one of the choices with this "easy" value, we are
effectively promoting pglz as a good choice. (I'm definitely one of
those people, if you give me too many options, I will look for some
hint what to do or walk away. Now 3 isn't "too many" but you get the
idea.)

I would like to see "on" to be moved to some better value (likely lz4,
like toast compression), and if some day, there is yet a better
choice, we should move it again.

Christoph

---

From: wenhui qiu <[email-masked]>
Date: Wed, 8 Jul 2026 14:37:36 +0800

Hi

> Yes, After PostgreSQL 19, lz4 became a required dependency unless you
> compile it yourself with --without-lz4. In most environments, lz4 is
> already installed, so along this code path the effective choice is
> essentially fixed to lz4.At cluster scale, it would make more sense to
> expose this parameter in the frontend as a boolean setting, rather than
> letting users choose from multiple compression options.

Thanks