Re: WAL compression setting after PostgreSQL LZ4 default change

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],
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]
https://postgr.es/m/CAGjGUAL6=2=gGTx_f4XeMpcJ0p8QMm+i8mX5rbC7VJXKbOGyNA@mail.gmail.com

--
Tomas Vondra