Re: Refactoring of compression options in pg_basebackup - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Refactoring of compression options in pg_basebackup
Date
Msg-id CAKFQuwYpDnaKmkJ=MeYfir0c9h3wMJFsx-a6LbteXB17t8tZ7w@mail.gmail.com
Whole thread Raw
In response to Re: Refactoring of compression options in pg_basebackup  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Mon, Jan 17, 2022 at 8:17 AM Robert Haas <robertmhaas@gmail.com> wrote:
On Mon, Jan 17, 2022 at 9:27 AM Magnus Hagander <magnus@hagander.net> wrote:
> I mean that I think it would be confusing to have
> --client-compression=x, --server-compression=y, and
> compression-level=z as the options. Why, in that scenario, does the
> "compression" part get two parameters, but the "compression level"
> part get one. In that case, there should either be --compression=x and
> --compression-level=z (which is what I'd suggest, per above), or there
> should be --client-compression, --server-compression,
> --client-compression-level and --server-compression-level, for it to
> be consistent. But having one of them be split in two parameters and
> the other one not, is what I'd consider confusing.

I don't find that confusing, but confusion is a pretty subjective
experience so that doesn't really prove anything. Of the two
alternatives that you propose, I prefer --compress=["server-"]METHOD
and --compression-level=NUMBER to having both
--client-compression-level and --server-compression-level. To me,
that's still a bit more surprising than my proposal, because having
the client compress stuff and having the server compress stuff feel
like somewhat different kinds of things ... but it's unsurprising that
I like my own proposal, and what really matters is that we converge
relatively quickly on something we can all live with.


Quick look-over of the email thread:

The bare "--compress" option isn't liked anymore.  I would prefer that we officially deprecate -z, -Z, and --compress but otherwise leave them alone for backward compatibility.

We do not want to entertain performing both server and client compression.  It thus seems undesirable to have different sets of options for them.  Therefore:

--compression-method={gzip|lz4|...}
--compression-level={string} (which can be any string value, the validation logic for compression-method will evaluate what is provided and error if it is not happy, each method would have its own default)
--compression-location={client|server} (Can be added once server compression is active.  I would suggest it would default to server-side compression - which would be a change in behavior by necessity)

If you really want a concise option here I say we make available:

--compression={method}[;string][;{client|server}]

The two trailing optional (with default) sub-arguments are unambiguous as to which one is present if only two sub-arguments are provided.

David J.

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Refactoring of compression options in pg_basebackup
Next
From: Zhihong Yu
Date:
Subject: Re: ExecRTCheckPerms() and many prunable partitions