Horton

Re: wal_compression=zstd

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Michael Paquier <michael@paquier.xyz>, Andrey Borodin <x4mmm@yandex-team.ru>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Heikki Linnakangas <hlinnaka@iki.fi>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Thomas Munro <thomas.munro@gmail.com>, Peter Geoghegan <pg@bowt.ie>, Andres Freund <andres@anarazel.de>
Date: 2022-03-04T13:08:03Z
Lists: pgsql-hackers 
On Fri, Mar 4, 2022 at 6:44 AM Justin Pryzby <pryzby@telsasoft.com> wrote:
> > Why?  ZSTD using this default has its reasons, no?  And it would be
> > consistent to do the same for ZSTD as for the other two methods.
>
> In my 1-off test, it gets 610/633 = 96% of the benefit at 209/273 = 77% of the
> cost.

I agree with Michael. Your 1-off test is exactly that, and the results
will have depended on the data you used for the test. I'm not saying
we could never decide to default to a compression level other than the
library's default, but I do not think we should do it casually or as
the result of any small number of tests. There should be a strong
presumption that the authors of the library have a good idea what is
sensible in general unless we can explain compellingly why our use
case is different from typical ones.

There's an ease-of-use concern here too. It's not going to make things
any easier for users to grok if zstd is available in different parts
of the system but has different defaults in each place. It wouldn't be
the end of the world if that happened, but neither would it be ideal.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

Commits

  1. Bump XLOG_PAGE_MAGIC due to the addition of wal_compression=zstd

  2. Add support for zstd with compression of full-page writes in WAL