Horton

Re: Different compression methods for FPI

x4mmm@yandex-team.ru

View thread View on postgr.es
From: Andrey Borodin <x4mmm@yandex-team.ru>
To: Michael Paquier <michael@paquier.xyz>
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-16T08:17:26Z
Lists: pgsql-hackers 

> 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.

BTW we could get rid of whole hole-in-a-page thing if we would set lz4 as default. This could simplify FPI code.

Thanks!

Best regards, Andrey Borodin.

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.