Re: WAL compression setting after PostgreSQL LZ4 default change

From: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Japin Li <japinli(at)hotmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, wenhui qiu <qiuwenhuifx(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, John Naylor <johncnaylorls(at)gmail(dot)com>, Christoph Berg <myon(at)debian(dot)org>
Subject: Re: WAL compression setting after PostgreSQL LZ4 default change
Date: 2026-07-07 22:46:53
Message-ID: CAGECzQQ+OWP+yafyUp_g3DDY-cKYoyATUEJRkgatLU6n70kH_A@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 8 Jul 2026 at 00:26, Michael Paquier <michael(at)paquier(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2026-07-07 22:58:14 Re: Add malloc attribute to memory allocation functions
Previous Message Dean Rasheed 2026-07-07 22:37:11 Re: Global temporary tables