Re: Refactoring of compression options in pg_basebackup
От | Michael Paquier |
---|---|
Тема | Re: Refactoring of compression options in pg_basebackup |
Дата | |
Msg-id | YeI3THZ1BEFa1x/j@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Refactoring of compression options in pg_basebackup (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Refactoring of compression options in pg_basebackup
|
Список | pgsql-hackers |
On Fri, Jan 14, 2022 at 04:53:12PM -0500, Robert Haas wrote: > On Thu, Jan 13, 2022 at 10:23 PM Michael Paquier <michael@paquier.xyz> wrote: >> 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. > > I could live with that. I'm not sure that --client-compress instead of > reusing --compress is going to be better ... but I don't think it's > awful so much as just not my first choice. I also don't think it would > be horrid to leave -z, --gzip, and -Z as shorthands for the > --client-compress=gzip with --compression-level also in the last case, > instead of removing all that stuff. Okay. So, based on this feedback, I guess that something like the attached would be what we are looking for. I have maximized the amount of code removed with the removal of -z/-Z, but I won't fight hard if the consensus is to keep them, either. We could also keep -z/--gzip, and stick -Z to the new --compression-level with --compress removed. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: