wal_compression=zstd - Mailing list pgsql-hackers

From Justin Pryzby
Subject wal_compression=zstd
Date
Msg-id 20220222231948.GJ9008@telsasoft.com
Whole thread Raw
Responses Re: wal_compression=zstd  (Michael Paquier <michael@paquier.xyz>)
Re: wal_compression=zstd  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Since 4035cd5d4, wal_compression=lz4 is supported.  I think pg15 should also
support wal_compression=zstd.  There are free bits in the WAL header.

The last message on that thread includes a patch doing just that, which I've
rebased.
https://www.postgresql.org/message-id/YNqWd2GSMrnqWIfx@paquier.xyz

It might be nice if to also support wal_compression=zstd-level, but that seems
optional and could wait for pg16...

In [0], I showed a case where lz4 is just as fast as uncompressed data, and
writes ~60% as much.  zstd writes half as much as LZ4 and 12% slower.
[0] https://www.postgresql.org/message-id/20210614012412.GA31772%40telsasoft.com

I am not claiming that zstd is generally better for WAL.  Rather, if we're
going to support alternate compression methods, it's nice to give a couple
options (in addition to pglz).  Some use cases would certainly suffer from
slower WAL.  But providing the option will benefit some others.  Note that a
superuser can set wal_compression for a given session - this would probably
benefit bulk-loading in an otherwise OLTP environment.

As writen, this patch uses zstd level=1 (whereas the ZSTD's default compress
level is 6).

0001 adds support for zstd
0002 makes more efficient our use of bits in the WAL header
0003 makes it the default compression, to exercise on CI (windows will fail).
0004 adds support for zstd-level
0005-6 are needed to allow recovery tests to pass when wal compression is enabled;
0007 (not included) also adds support for zlib.  I'm of the impression nobody
     cares about this, otherwise it would've been included 5-10 years ago.

Only 0001 should be reviewed for pg15 - the others are optional/future work.

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: making pg_regress less noisy by removing boilerplate
Next
From: Tom Lane
Date:
Subject: Re: Frontend error logging style