Re: WAL compression setting after PostgreSQL LZ4 default change

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

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2026-07-16 22:11:18 Re: Hash index AM fake LSN oversight
Previous Message Logan Saso 2026-07-16 21:55:37 [PATCH] Ignore duplicate IS [NOT] NULL clauses in clauselist_selectivity()