Re: Refactoring of compression options in pg_basebackup

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Refactoring of compression options in pg_basebackup
Дата
Msg-id CAKFQuwaKu75fAkh2QsAp+DgAgj+EU=BiT2nKoRRoaj_fJ7xAQg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Refactoring of compression options in pg_basebackup  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: Refactoring of compression options in pg_basebackup  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Mon, Jan 17, 2022 at 8:41 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
On 2022-Jan-17, Robert Haas wrote:

> 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.

I think having a single option where you specify everything is simpler.
I propose we accept these forms:

--compress=[{server,client}-]method[:level]     new in 15
--compress=level                (accepted by 14)
-Z level                        (accepted by 14)
-z                              (accepted by 14)

I am also in favor of this option.  Whether this is better than deprecating --compress and introducing --compression I am having trouble deciding.  My personal preference is to add --compression and leave --compress alone and deprecated; but we don't usually do anything with deprecations and having users seeing both --compress and --compression out in the wild, even if never at the same time, is bound to elicit questions (though so is seeing --compress with "number only" rules and "composite value" rules...)


This way, compatibility with the existing release is maintained; and we
introduce all the new functionality without cluttering the interface.

I would still "clutter" the interface with:

--compress-method
--compress-options (extending from my prior post, I would make this more generic - i.e., not named "level" -  and deal with valid values, meaning, and format, in a per-method description in the documentation)
--compress-location

Users have different preferences for what they want to use, and it provides a level of self-documentation for the composite specification and a degree of explicitness for the actual documentation of the methods.

One missing feature in this spec is the ability to specify compression
to be used with whatever the default method is.  I'm not sure we want to
allow for that

I'm not too keen on making a default method in code.  Saying "if in doubt gzip is a widely used compression method." in the documentation seems sufficient.

David J.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: a misbehavior of partition row movement (?)
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: Avoiding smgrimmedsync() during nbtree index builds