Обсуждение: change default default_toast_compression to lz4?
How about changing the default of default_toast_compression to lz4? I have seen cases where servers had performance problems and were CPU-bound because of pglz TOAST compression, and changing it to lz4 relieved it significantly. I suspect many users are leaving easy performance improvements on the table by not using this option. The feature was introduced in PostgreSQL 14, so it should be well stabilized now. I suppose one issue is that lz4 support is not compiled-in by default, but in practice most users will have it. The default could be lz4 if lz4 support is built, otherwise pglz. This would be similar to other parameters where the default is the best one depending on the build configuration.
Hi Peter, > How about changing the default of default_toast_compression to lz4? To me it sounds like a great idea. > I have seen cases where servers had performance problems and were > CPU-bound because of pglz TOAST compression, and changing it to lz4 > relieved it significantly. I suspect many users are leaving easy > performance improvements on the table by not using this option. > > The feature was introduced in PostgreSQL 14, so it should be well > stabilized now. > > I suppose one issue is that lz4 support is not compiled-in by default, > but in practice most users will have it. The default could be lz4 if > lz4 support is built, otherwise pglz. This would be similar to other > parameters where the default is the best one depending on the build > configuration. Are there good reasons why we can't simply make lz4 a required dependency? In the worst case we could simply copy its implementation, the license permits. -- Best regards, Aleksander Alekseev
> On 21 Nov 2025, at 12:33, Aleksander Alekseev <aleksander@tigerdata.com> wrote: >> The default could be lz4 if >> lz4 support is built, otherwise pglz. This would be similar to other >> parameters where the default is the best one depending on the build >> configuration. +1 > Are there good reasons why we can't simply make lz4 a required > dependency? In the worst case we could simply copy its implementation, > the license permits. I think we should, as much as we can, avoid vendoring code, especially something like lz4 which can be expected to be available nearly everywhere. -- Daniel Gustafsson
Hi, On 2025-11-21 12:11:38 +0100, Peter Eisentraut wrote: > How about changing the default of default_toast_compression to lz4? > > I have seen cases where servers had performance problems and were CPU-bound > because of pglz TOAST compression, and changing it to lz4 relieved it > significantly. I suspect many users are leaving easy performance > improvements on the table by not using this option. +1 - I also have seen *and* hit this numerous times. IIRC it makes the tests runs a tad bit faster too. > I suppose one issue is that lz4 support is not compiled-in by default, but > in practice most users will have it. The default could be lz4 if lz4 > support is built, otherwise pglz. This would be similar to other parameters > where the default is the best one depending on the build configuration. I think we should mark lz4 as a default-required dependency if we change the default. That way one needs to explicitly opt into a build that won't be compatible with existing data directories created (due to pre-existing lz4 . Greetings, Andres Freund
Andres Freund <andres@anarazel.de> writes:
> On 2025-11-21 12:11:38 +0100, Peter Eisentraut wrote:
>> I suppose one issue is that lz4 support is not compiled-in by default, but
>> in practice most users will have it. The default could be lz4 if lz4
>> support is built, otherwise pglz. This would be similar to other parameters
>> where the default is the best one depending on the build configuration.
> I think we should mark lz4 as a default-required dependency if we change the
> default. That way one needs to explicitly opt into a build that won't be
> compatible with existing data directories created (due to pre-existing lz4 .
Agreed --- we should make it act like icu or readline, you have to
opt out. (I'm not voting one way or the other on changing the
default, but if we do we should do it that way.)
regards, tom lane
On 2025-Nov-21, Daniel Gustafsson wrote: > > On 21 Nov 2025, at 12:33, Aleksander Alekseev <aleksander@tigerdata.com> wrote: > > > Are there good reasons why we can't simply make lz4 a required > > dependency? In the worst case we could simply copy its implementation, > > the license permits. > > I think we should, as much as we can, avoid vendoring code, especially > something like lz4 which can be expected to be available nearly everywhere. Yeah. There's the security aspect: if lz4 is found to have a security bug, we would be obliged to issue an advisory and matching release. It's best if the library code is kept separate, so their own security advisory is enough. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/