Re: Refactoring of compression options in pg_basebackup

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, 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 15:42:12
Message-ID: CAKFQuwYpDnaKmkJ=MeYfir0c9h3wMJFsx-a6LbteXB17t8tZ7w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 17, 2022 at 8:17 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Mon, Jan 17, 2022 at 9:27 AM Magnus Hagander <magnus(at)hagander(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zhihong Yu 2022-01-17 15:45:06 Re: ExecRTCheckPerms() and many prunable partitions
Previous Message Alvaro Herrera 2022-01-17 15:41:44 Re: Refactoring of compression options in pg_basebackup