Re: zstd compression for pg_dump
От | Tomas Vondra |
---|---|
Тема | Re: zstd compression for pg_dump |
Дата | |
Msg-id | 27eb89fc-8fdd-2988-0959-0af1d6d7a12a@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: zstd compression for pg_dump (Justin Pryzby <pryzby@telsasoft.com>) |
Ответы |
Re: zstd compression for pg_dump
|
Список | pgsql-hackers |
On 4/3/23 21:17, Justin Pryzby wrote: > On Sat, Apr 01, 2023 at 10:26:01PM +0200, Tomas Vondra wrote: >>> Feel free to mess around with threads (but I'd much rather see the patch >>> progress for zstd:long). >> >> OK, understood. The long mode patch is pretty simple. IIUC it does not >> change the format, i.e. in the worst case we could leave it for PG17 >> too. Correct? > > Right, libzstd only has one "format", which is the same as what's used > by the commandline tool. zstd:long doesn't change the format of the > output: the library just uses a larger memory buffer to allow better > compression. There's no format change for zstd:workers, either. > OK. I plan to do a bit more review/testing on this, and get it committed over the next day or two, likely including the long mode. One thing I noticed today is that maybe long_distance should be a bool, not int. Yes, ZSTD_c_enableLongDistanceMatching() accepts int, but it'd be cleaner to cast the value during a call and keep it bool otherwise. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: