Re: Different compression methods for FPI

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Heikki Linnakangas <hlinnaka@iki.fi>, pgsql-hackers <pgsql-hackers@postgresql.org>, Thomas Munro <thomas.munro@gmail.com>, Peter Geoghegan <pg@bowt.ie>, Andres Freund <andres@anarazel.de>
Date: 2021-06-17T06:44:26Z
Lists: pgsql-hackers
On Thu, Jun 17, 2021 at 10:19:47AM +0900, Michael Paquier wrote:
> Yeah, I am tempted to just add LZ4 as a first step as the patch
> footprint would be minimal, and we could come back to zstd once we
> have more feedback from the field, if that's necessary.  As said
> upthread, we have more flexibility with WAL than for the relation
> data.

I have worked more on that today and finished with two patches:
- 0001 is the mininal patch to add support for LZ4.  This is in a
rather committable shape.  I noticed that we checked for an incorrect
error code in the compression and decompression paths as LZ4 APIs can
return a negative result.  There were also some extra bugs I spotted.
Its size is satisfying for what it does, and there is MSVC support
out-of-the-box:
 12 files changed, 176 insertions(+), 48 deletions(-)
- 0002 is the extra code need to add ZSTD and do the same.  This still
requires support for MSVC and I have not checked the internals of ZSTD
to see if we do the compress/decompress calls the right way.

While on it, I am going to switch my buildfarm animal to use LZ4 for
toast..  Just saying.
--
Michael

Commits

  1. Add more error context to RestoreBlockImage() and consume it

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

  3. Extended statistics on expressions

  4. Be clear about whether a recovery pause has taken effect.

  5. Add GUC to enable compression of full page images stored in WAL.