Subject: Re: Different compression methods for FPI
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>
References: <20210525044444.GV3676@telsasoft.com>
 <YKymshLnYZeD0cue@paquier.xyz>
 <3252174C-C21D-4711-A038-5230DE465BAE@yandex-team.ru>
 <YLWWPaq/KnVS24J4@paquier.xyz> <20210614012412.GA31772@telsasoft.com>
 <YMf5YQVpDLUf+WoQ@paquier.xyz> <20210615014208.GK31772@telsasoft.com>
 <YMgS3DxyLj7Dqx7S@paquier.xyz> <20210615034206.GL31772@telsasoft.com>
 <a5e263ea-82d3-186f-1abf-a661c5f673af@iki.fi> <YMg8hz/hpl8Qr3bM@paquier.xyz>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Message-ID: <d220fdbf-c9fc-6408-ff2b-07f5a9a23e2c@enterprisedb.com>
Date: Tue, 15 Jun 2021 07:53:26 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
 Gecko/20100101 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: <YMg8hz/hpl8Qr3bM@paquier.xyz>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/d220fdbf-c9fc-6408-ff2b-07f5a9a23e2c%40enterprisedb.com>
Precedence: bulk

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.