Re: Different compression methods for FPI

On 15/06/2021 06:42, Justin Pryzby wrote:
> On Tue, Jun 15, 2021 at 11:39:24AM +0900, Michael Paquier wrote:
>> On Mon, Jun 14, 2021 at 08:42:08PM -0500, Justin Pryzby wrote:
>>>>> It's USERSET following your own suggestion (which is a good suggestion):
>>>> + {"wal_compression_method", PGC_SIGHUP, WAL_SETTINGS,
>>>> + gettext_noop("Set the method used to compress full page images in the WAL."),
>>>> + NULL
>>>> + },
>>>> + &wal_compression_method,
>>>> + WAL_COMPRESSION_PGLZ, wal_compression_options,
>>>> + NULL, NULL, NULL
>>>> Any reason to not make that user-settable? If you merge that with
>>>> wal_compression, that's not an issue.
>>
>> Hmm, yeah. This can be read as using PGC_USERSET. With the second
>> part of my sentence, I think that I imply to use PGC_SUSET and be
>> consistent with wal_compression, but I don't recall my mood from one
>> month ago :) Sorry for the confusion.
>
> Hold on - we're all confused (and I'm to blame). The patch is changing the
> existing wal_compression GUC, rather than adding wal_compression_method.
> It's still SUSET, but in earlier messages, I called it USERSET, twice.

See prior discussion on the security aspect:
https://www.postgresql.org/message-id/55269915.1000309%40iki.fi. Adding
different compression algorithms doesn't change anything from a security
point of view AFAICS.

>>> The goal of the patch is to give options, and the overhead of adding both zlib
>>> and lz4 is low. zlib gives good compression at some CPUcost and may be
>>> preferable for (some) DWs, and lz4 is almost certainly better (than pglz) for
>>> OLTPs.
>>
>> Anything will be better than pglz. I am rather confident in that.
>> What I am wondering is if we need to eat more bits than necessary for
>> the WAL record format, because we will end up supporting it until the
>> end of times.
>
> Why ? This is WAL, not table data. WAL depends on the major version, so
> I think wal_compression could provide a different set of compression methods at
> every major release?
>
> 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

- Heikki