Horton

Thread

  1. WAL compression setting after PostgreSQL LZ4 default change

    wenhui qiu <qiuwenhuifx@gmail.com> — 2026-06-30T10:25:09Z

    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

  2. Re: WAL compression setting after PostgreSQL LZ4 default change

    Christoph Berg <myon@debian.org> — 2026-06-30T10:51:13Z

    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

  3. Re: WAL compression setting after PostgreSQL LZ4 default change

    Japin Li <japinli@hotmail.com> — 2026-06-30T13:48:50Z

    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.

  4. Re: WAL compression setting after PostgreSQL LZ4 default change

    Michael Paquier <michael@paquier.xyz> — 2026-06-30T23:45:17Z

    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

  5. Re: WAL compression setting after PostgreSQL LZ4 default change

    wenhui qiu <qiuwenhuifx@gmail.com> — 2026-07-01T01:53:36Z

    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

  6. Re: WAL compression setting after PostgreSQL LZ4 default change

    Japin Li <japinli@hotmail.com> — 2026-07-03T02:18:08Z

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

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

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

  7. Re: WAL compression setting after PostgreSQL LZ4 default change

    Fujii Masao <masao.fujii@gmail.com> — 2026-07-03T02:58:52Z

    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

  8. Re: WAL compression setting after PostgreSQL LZ4 default change

    Japin Li <japinli@hotmail.com> — 2026-07-03T08:38:06Z

    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.

  9. Re: WAL compression setting after PostgreSQL LZ4 default change

    Michael Paquier <michael@paquier.xyz> — 2026-07-07T22:26:34Z

    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

  10. Re: WAL compression setting after PostgreSQL LZ4 default change

    Jelte Fennema-Nio <postgres@jeltef.nl> — 2026-07-07T22:46:53Z

    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.

  11. Re: WAL compression setting after PostgreSQL LZ4 default change

    Christoph Berg <myon@debian.org> — 2026-07-07T22:58:59Z

    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

  12. Re: WAL compression setting after PostgreSQL LZ4 default change

    wenhui qiu <qiuwenhuifx@gmail.com> — 2026-07-08T06:37:36Z

    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