Re: refactoring basebackup.c (zstd workers)
От | Robert Haas |
---|---|
Тема | Re: refactoring basebackup.c (zstd workers) |
Дата | |
Msg-id | CA+TgmoYvpetyRAbbg1M8b3-iHsaN4nsgmWPjOENu5-doHuJ7fA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: refactoring basebackup.c (zstd workers) (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: refactoring basebackup.c (zstd workers)
|
Список | pgsql-hackers |
On Mon, Mar 14, 2022 at 1:21 PM Robert Haas <robertmhaas@gmail.com> wrote: > There's some appeal to that, but one downside is that it means that > the client can't be used to fetch data that is compressed in a way > that the server knows about and the client doesn't. I don't think > that's great. Why should, for example, pg_basebackup need to be > compiled with zstd support in order to request zstd compression on the > server side? If the server knows about the brand new > justin-magic-sauce compression algorithm, maybe the client should just > be able to request it and, when given various .jms files by the > server, shrug its shoulders and accept them for what they are. That > doesn't work if -Fp is involved, or similar, but it should work fine > for simple cases if we set things up right. Concretely, I propose the attached patch for v15. It renames the newly-added COMPRESSION_LEVEL option to COMPRESSION_DETAIL, introduces a flexible syntax for options along the lines you proposed, and adjusts things so that a client that doesn't support a particular type of compression can still request that type of compression from the server. I think it's important to do this for v15 so that we don't end up with backward-compatibility problems down the road. -- Robert Haas EDB: http://www.enterprisedb.com
Вложения
В списке pgsql-hackers по дате отправления: