Re: Refactoring of compression options in pg_basebackup

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Refactoring of compression options in pg_basebackup
Дата
Msg-id CABUevEzSv7VtaG44QFjrYaRvnQs4qy4c=-3NppCDH+nZVNfdEA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Refactoring of compression options in pg_basebackup  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Refactoring of compression options in pg_basebackup  (Michael Paquier <michael@paquier.xyz>)
Re: Refactoring of compression options in pg_basebackup  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Fri, Jan 14, 2022 at 10:53 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Thu, Jan 13, 2022 at 10:23 PM Michael Paquier <michael@paquier.xyz> wrote:
> > Using --compression-level=NUMBER and --server-compress=METHOD to
> > specify a server-side compression method with a level is fine by me,
> > but I find the reuse of --compress to specify a compression method
> > confusing as it maps with the past option we have kept in
> > pg_basebackup for a couple of years now.  Based on your suggested set
> > of options, we could then have a --client-compress=METHOD and
> > --compression-level=NUMBER to specify a client-side compression method
> > with a level.  If we do that, I guess that we should then:
> > 1) Block the combination of --server-compress and --client-compress.
> > 2) Remove the existing -Z/--compress and -z/--gzip.
>
> I could live with that. I'm not sure that --client-compress instead of
> reusing --compress is going to be better ... but I don't think it's
> awful so much as just not my first choice. I also don't think it would
> be horrid to leave -z, --gzip, and -Z as shorthands for the
> --client-compress=gzip with --compression-level also in the last case,
> instead of removing all that stuff.

It never makes sense to compress *both* in server and client, right?

One argument in that case for using --compress would be that we could
have that one take options like --compress=gzip (use gzip in the
client) and --compress=server-lz4 (use lz4 on the server), and
automatically make it impossible to do both. And maybe also accept
--compress=client-gzip (which would be the same as just specifying
gzip).

That would be an argument for actually keeping --compress and not
using --client-compress, because obviously it would be silly to have
--client-compress=server-lz4...

And yes, I agree that considering both server and client compression
even if we don't have server compression makes sense, since we don't
want to change things around again when we get it.

We could perhaps also consider accepting --compress=gzip:7
(<method>:<level>) as a way to specify the level, for both client and
server side.

I think having --client-compress and --server-compress separately but
having --compression-level *not* being separate would be confusing and
I *think* that's what the current patch proposes?

-- 
 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/



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

Предыдущее
От: Bharath Rupireddy
Дата:
Сообщение: Re: Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: MultiXact/SLRU buffers configuration