Re: WAL compression setting after PostgreSQL LZ4 default change

On 7/16/26 17:08, Andres Freund wrote:
> 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).
>

Ack. What do you think about doing this for PG19? Or do you think that
ship has sailed at this point?

regards

--
Tomas Vondra