Horton

Re: Different compression methods for FPI

Heikki Linnakangas <hlinnaka@iki.fi>

View thread View on postgr.es
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Andrey Borodin <x4mmm@yandex-team.ru>, Michael Paquier <michael@paquier.xyz>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, 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-16T08:49:51Z
Lists: pgsql-hackers 
On 16/06/2021 11:17, Andrey Borodin wrote:
>> 16 июня 2021 г., в 12:18, Michael Paquier <michael@paquier.xyz> написал(а):
>>   Among the
>> remaining two I would be tempted to choose LZ4.  That's consistent
>> with what toast can use now.
> 
> I agree that allowing just lz4 - is already a huge step ahead.
> 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.

Hmm, do we currently compress each block in a WAL record separately, for 
records that contain multiple full-page images? That could make a big 
difference e.g. for GiST index build that WAL-logs 32 pages in each 
record. If it helps the compression, we should probably start 
WAL-logging b-tree index build in larger batches, too.

- Heikki

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.