| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de>, 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>, Michael Paquier <michael(at)paquier(dot)xyz>, 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-18 20:28:48 |
| Message-ID: | 1314f5843859d5f83d5eb0a47b15d9291567cf40.camel@cybertec.at |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 2026-07-16 at 11:08 -0400, Andres Freund wrote:
> On 2026-07-16 17:00:58 +0200, Tomas Vondra wrote:
> > * 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.
+1
It would be compelling to make this change for v19, so that it is in line
with the change for "default_toast_compression". But I guess it is too late
in the cycle for that.
Yours,
Laurenz Albe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Gustafsson | 2026-07-18 21:08:47 | Re: pg_plan_advice: fix parsing underscore in numbers |
| Previous Message | Etsuro Fujita | 2026-07-18 19:59:38 | Re: Bug in asynchronous Append |