On Thu, Jan 13, 2022 at 01:36:00PM -0500, Robert Haas wrote: > 1. If, as you propose, we add a new flag --compression-method=METHOD > then how will the user specify server-side compression?
This would require a completely different option switch, which is basically the same thing as what you are suggesting with --server-compress. > 2. If, as we seem to agree, the compression method is more important > than the compression level, then why is the option to set the > less-important thing called just --compress, and the option to set the > more important thing has a longer name? I agree that the method is more important than the level for most users, and I would not mind dropping completely --compress in favor of something else, which is something I implied upthread. > I proposed to solve both of these problems by using > --compression-level=NUMBER to set the compression level and > --compress=METHOD or --server-compress=METHOD to set the algorithm and > specify on which side it is to be applied. If, instead of doing that, > we go with what you have proposed here, then I don't understand how to > fit server-side compression into the framework in a reasonably concise > way. I think we would end up with something like pg_basebackup > --compression-method=lz4 --compress-on-server, which seems rather long > and awkward. Do you have a better idea? 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. You have implied 1) upthread as far as I recall, 2) is something I am adding on top of it. > I think I understand what the patch is doing. I just think it creates > a problem for my patch. And I'd like to know whether you have an idea > how to solve that problem. And if not, then I'd like you to consider > the solution that I am proposing rather than the patch you've already > got. I am fine to drop this thread's patch with its set of options and work on top of your proposal, aka what's drafted two paragraphs above. -- Michael
signature.asc
Description: PGP signature
