On Sat, Jan 15, 2022 at 10:15 AM Magnus Hagander <magnus@hagander.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 the current patch proposes?
Depends on what you mean by "separate". There's no proposal to have
--client-compression-level and also --server-compression-level.
--
Robert Haas
EDB: http://www.enterprisedb.com
