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+i8mx5rbc7vjxkbog...@mail.gmail.com -- Tomas Vondra
