| From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, pgsql-hackers(at)postgresql(dot)org, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, Andres Freund <andres(at)anarazel(dot)de> |
| Subject: | Re: Different compression methods for FPI |
| Date: | 2021-06-15 05:53:26 |
| Message-ID: | d220fdbf-c9fc-6408-ff2b-07f5a9a23e2c@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kyotaro Horiguchi | 2021-06-15 06:16:33 | Re: Race condition in recovery? |
| Previous Message | Michael Paquier | 2021-06-15 05:37:11 | Re: Different compression methods for FPI |