Re: Refactoring of compression options in pg_basebackup

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Refactoring of compression options in pg_basebackup
Дата
Msg-id CAKFQuwYpDnaKmkJ=MeYfir0c9h3wMJFsx-a6LbteXB17t8tZ7w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Refactoring of compression options in pg_basebackup  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Refactoring of compression options in pg_basebackup
Следующее
От: Zhihong Yu
Дата:
Сообщение: Re: ExecRTCheckPerms() and many prunable partitions