WAL compression setting after PostgreSQL LZ4 default change

Re: wenhui qiu

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?

+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

On Tue, 30 Jun 2026 at 12:51, Christoph Berg <myon@debian.org> wrote:

Re: wenhui qiu

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?

+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.

+1. LGTM.

Christoph

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

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

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

On Wed, 01 Jul 2026 at 09:53, wenhui qiu <qiuwenhuifx@gmail.com> wrote:

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

Thanks for updating the patch. I've registered it in the CommitFest [1]https://commitfest.postgresql.org/patch/6979/.

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

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

On Wed, Jul 1, 2026 at 8:45 AM Michael Paquier <michael@paquier.xyz> wrote:

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.

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

On Fri, 03 Jul 2026 at 11:58, Fujii Masao <masao.fujii@gmail.com> wrote:

On Wed, Jul 1, 2026 at 8:45 AM Michael Paquier <michael@paquier.xyz> wrote:

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.

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".

Understood. I'll withdraw this from the CommitFest.

Regards,

--
Fujii Masao

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

On Fri, Jul 03, 2026 at 04:38:06PM +0800, Japin Li wrote:

On Fri, 03 Jul 2026 at 11:58, Fujii Masao <masao.fujii@gmail.com> wrote:

On Wed, Jul 1, 2026 at 8:45 AM Michael Paquier <michael@paquier.xyz> wrote:

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.

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".

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

On Wed, 8 Jul 2026 at 00:26, Michael Paquier <michael@paquier.xyz> wrote:

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.

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.

Re: Jelte Fennema-Nio

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.

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

Hi

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.

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

Hi,

On 7/8/26 08:37, wenhui qiu wrote:

Hi 

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.

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 

I've been reminded of this proposal by a message in another thread [1]/messages/by-id/CAGjGUAL6=2=gGTx_f4XeMpcJ0p8QMm+i8mX5rbC7VJXKbOGyNA@mail.gmail.com,
which suggests this proposal (to adjust the wal_compression default) was
not accepted.

Which seems strange to me, and I suspect it's a misunderstanding. From
the discussion in this thread it seems to me that:

* the proposal is to change what 'on' means - currently it's always
pglz, but the proposal would change this to the "best" available
algorithm (so lz4)

* the wal_compression default would remain "off"

I think this proposal makes sense, and at least Michael and Christoph
seem to agree with that.

Fujii Masao disagrees, arguing to leave "on" as it 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".

I understand the sentiment, but ISTM the argument "if you want lz4 or
zstd, you can specify that" can just as well be used in favor of the
proposal (because users have a way to eliminate the confusion).

The core question is whether we should stick to "on" meaning "pglz"
forever, because it once did. Or whether we should treat "on" as a
generic "do compression", and the database should be able to choose the
best supported algorithm.

My opinion is "on" should be a generic "pick compression" option, giving
the database the mandate to pick an algorithm. A user who wants a
particular algorithm can specify that.

The only reason why "on" means "pglz" is that initially that was the
only supported algorithm (until PG 15). But if we supported multiple
algorithms from the beginning, would we do it that way? I don't think
so. We'd either not have "on" at all, or it'd pick the best algorithm.

regards

[1]: /messages/by-id/CAGjGUAL6=2=gGTx_f4XeMpcJ0p8QMm+i8mX5rbC7VJXKbOGyNA@mail.gmail.com
/messages/by-id/CAGjGUAL6=2=gGTx_f4XeMpcJ0p8QMm+i8mX5rbC7VJXKbOGyNA@mail.gmail.com

--
Tomas Vondra

Hi,

On 2026-07-16 17:00:58 +0200, Tomas Vondra wrote:

On 7/8/26 08:37, wenhui qiu wrote:

Hi 

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.

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 

I've been reminded of this proposal by a message in another thread [1],
which suggests this proposal (to adjust the wal_compression default) was
not accepted.

Which seems strange to me, and I suspect it's a misunderstanding. From
the discussion in this thread it seems to me that:

* the proposal is to change what 'on' means - currently it's always
pglz, but the proposal would change this to the "best" available
algorithm (so lz4)

* the wal_compression default would remain "off"

I think this proposal makes sense, and at least Michael and Christoph
seem to agree with that.

+1 from me too.

I've seen way too many incidents where wal_compression was very useful but due
to the use of pglz slowed down crucial, single threaded, parts of the workload
down so much that it had to be disabled again. We should not make it our
users responsibility to know that the 'on' maps to an almost unusably slow
compression algorithm.

The compatibility concerns are *much* higher for toast compression than for
wal compression, given that toast compression means that you have to build
with the chosen compression pretty much forever, given that the compressed
datum survive pg_upgrade. Whereas wal compression doesn't survive pg_upgrade (
and you probably could even get away with just running with
wal_compression=off for a while and then removing support for the relevant
compression method).

Greetings,

Andres Freund

On Thu, Jul 16, 2026 at 05:00:58PM +0200, Tomas Vondra wrote:

My opinion is "on" should be a generic "pick compression" option, giving
the database the mandate to pick an algorithm. A user who wants a
particular algorithm can specify that.

The only reason why "on" means "pglz" is that initially that was the
only supported algorithm (until PG 15). But if we supported multiple
algorithms from the beginning, would we do it that way? I don't think
so. We'd either not have "on" at all, or it'd pick the best algorithm.

I have worked on both things. I cannot go back in time, but I suspect
that I would have picked up pglz as default for "on" out of safety as
a start point.

A few releases later, where I know that many deployments are using
either lz4 or zstd and nobody has complained back, I see a much better
argument in changing the behavior of "on" to mean "zstd" -> "lz4" ->
"pglz" in order of priority, based on how efficient these algorithms
are known to be.
--
Michael

On Thu, 2026-07-16 at 11:08 -0400, Andres Freund wrote:

On 2026-07-16 17:00:58 +0200, Tomas Vondra wrote:

* the proposal is to change what 'on' means - currently it's always
pglz, but the proposal would change this to the "best" available
algorithm (so lz4)

* the wal_compression default would remain "off"

I think this proposal makes sense, and at least Michael and Christoph
seem to agree with that.

+1 from me too.

I've seen way too many incidents where wal_compression was very useful but due
to the use of pglz slowed down crucial, single threaded, parts of the workload
down so much that it had to be disabled again. We should not make it our
users responsibility to know that the 'on' maps to an almost unusably slow
compression algorithm.

+1

It would be compelling to make this change for v19, so that it is in line
with the change for "default_toast_compression". But I guess it is too late
in the cycle for that.

Yours,
Laurenz Albe

HI

A few releases later, where I know that many deployments are using
either lz4 or zstd and nobody has complained back, I see a much better
argument in changing the behavior of "on" to mean "zstd" -> "lz4" ->
"pglz" in order of priority, based on how efficient these algorithms
are known to be.

V2 path does exactly that.

It would be compelling to make this change for v19, so that it is in line
with the change for "default_toast_compression". But I guess it is too

late

in the cycle for that.

The feature was frozen in April. It won't be too late to include it in
Version 20—better late than never.

Thanks