Horton

Re: Different compression methods for FPI

Peter Eisentraut <peter.eisentraut@enterprisedb.com>

View thread View on postgr.es
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Michael Paquier <michael@paquier.xyz>, Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Andrey Borodin <x4mmm@yandex-team.ru>, pgsql-hackers@postgresql.org, Thomas Munro <thomas.munro@gmail.com>, Peter Geoghegan <pg@bowt.ie>, Andres Freund <andres@anarazel.de>
Date: 2021-06-15T05:53:26Z
Lists: pgsql-hackers 
On 15.06.21 07:37, Michael Paquier wrote:
>>> Actually, I was just thinking that default yes/no/on/off stuff maybe should be
>>> defined to mean "lz4" rather than meaning pglz for "backwards compatibility".
>> +1
> I am not sure that we have any reasons to be that aggressive about
> this one either, and this would mean that wal_compression=on implies a
> different method depending on the build options.  I would just stick
> with the past, careful practice that we have to use a default
> backward-compatible value as default, while being able to use a new
> option.

If we think this new thing is strictly better than the old thing, then 
why not make it the default.  What would be the gain from sticking to 
the old default?

The point that the default would depend on build options is a valid one. 
  I'm not sure whether it's important enough by itself.

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.