Re: refactoring basebackup.c (zstd workers)
От | Robert Haas |
---|---|
Тема | Re: refactoring basebackup.c (zstd workers) |
Дата | |
Msg-id | CA+TgmoaYrNxoGB8x_7Fk5uKXfbyMVAdSXTnfQN-1zu_3gB_v=Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: refactoring basebackup.c (Jeevan Ladhe <jeevanladhe.os@gmail.com>) |
Ответы |
Re: refactoring basebackup.c (zstd workers)
|
Список | pgsql-hackers |
On Mon, Mar 14, 2022 at 12:35 PM Justin Pryzby <pryzby@telsasoft.com> wrote: > I suggest to use a syntax that's more general than that, maybe something like > > :[level=]N,parallel=N,flag,flag,... > > For example, someone may want to use zstd "long" mode or (when it's released) > rsyncable mode, or specify fine-grained compression parameters (strategy, > windowLog, hashLog, etc). That's an interesting idea. I wonder what the replication protocol ought to look like in that case. Should we have a COMPRESSION_DETAIL argument that is just a string, and let the server parse it out? Or separate protocol-level options? It does feel reasonable to have both COMPRESSION_LEVEL and COMPRESSION_WORKERS as first-class options, but I don't know that we want COMPRESSION_HASHLOG true as part of our first-class grammar. > I hope the same syntax will be shared with wal_compression and pg_dump. > And libpq, if that patch progresses. > > BTW, I think this may be better left for PG16. Possibly so ... but if we're thinking of any revisions to the newly-added grammar, we had better take care of that now, before it's set in stone. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: