On Sat, Jan 15, 2022 at 10:15 AM Magnus Hagander <mag...@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