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
-
Add more error context to RestoreBlockImage() and consume it
- 0a7c9ee50062 15.0 landed
- df4a056619a7 16.0 landed
-
Add support for LZ4 with compression of full-page writes in WAL
- 4035cd5d4eee 15.0 landed
-
Extended statistics on expressions
- a4d75c86bf15 14.0 cited
-
Be clear about whether a recovery pause has taken effect.
- 32fd2b57d7f6 14.0 cited
-
Add GUC to enable compression of full page images stored in WAL.
- 57aa5b2bb11a 9.5.0 cited