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-17T01:19:47Z
Lists: pgsql-hackers
On Wed, Jun 16, 2021 at 01:17:26PM +0500, Andrey Borodin wrote: > I agree that allowing just lz4 - is already a huge step ahead. 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. > But I'd suggest supporting zstd as well. Currently we only compress > 8Kb chunks and zstd had no runaway to fully unwrap it's potential. > In WAL-G we observed ~3x improvement in network utilisation when > switched from lz4 to zstd in WAL archive compression. You mean full segments here, right? This has no need to be in core, except if we want to add more compression options to pg_receivewal and its friends? That would be a nice addition, saying that. > BTW we could get rid of whole hole-in-a-page thing if we would set > lz4 as default. This could simplify FPI code. Why would we do that? We still need to support pglz as fallback if a platform does not have LZ4, no? -- 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