Re: Refactoring of compression options in pg_basebackup

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Georgios Kokolatos <gkokolatos(at)pm(dot)me>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Jeevan Ladhe <jeevan(dot)ladhe(at)enterprisedb(dot)com>
Subject: Re: Refactoring of compression options in pg_basebackup
Date: 2022-01-17 14:27:38
Message-ID: CABUevExyMRUCAA3n+40Vm6oZFQvnKzXqfakQvA4cqU1coyO=OQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 17, 2022 at 3:18 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Sat, Jan 15, 2022 at 10:15 AM Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> > It never makes sense to compress *both* in server and client, right?
>
> Yeah.
>
> > 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...
>
> I still like distinguishing it using the option name, but differently:
> --compress=METHOD and --server-compress=METHOD. But this is also a
> reasonable proposal.
>
> > 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.
>
> Especially not because I'm pretty close to having a committable patch
> and intend to try to get this into v15. See the refactoring
> basebackup.c thread.
>
> > We could perhaps also consider accepting --compress=gzip:7
> > (<method>:<level>) as a way to specify the level, for both client and
> > server side.
>
> That's not crazy either. Initially I was thinking --compression=gzip7
> but then it turns out lz4 is one of the methods we want to use, and
> lz47 would be, err, slightly unclear. lz4:7 is better, for sure.
>
> > 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 th e current patch proposes?
>
> Depends on what you mean by "separate". There's no proposal to have
> --client-compression-level and also --server-compression-level.

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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2022-01-17 14:29:02 Re: Refactoring of compression options in pg_basebackup
Previous Message Alvaro Herrera 2022-01-17 14:25:53 Re: a misbehavior of partition row movement (?)