Re: zstd compression for pg_dump
Justin Pryzby <pryzby@telsasoft.com>
From: Justin Pryzby <pryzby@telsasoft.com>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Jacob Champion <jchampion@timescale.com>, pgsql-hackers@postgresql.org, gkokolatos@pm.me, Michael Paquier <michael@paquier.xyz>, Robert Haas <robertmhaas@gmail.com>, Peter Geoghegan <pg@bowt.ie>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Thomas Munro <thomas.munro@gmail.com>, Dipesh Pandit <dipesh.pandit@gmail.com>, Andrey Borodin <x4mmm@yandex-team.ru>, Mark Dilger <mark.dilger@enterprisedb.com>
Date: 2023-04-06T16:10:17Z
Lists: pgsql-hackers
On Thu, Apr 06, 2023 at 05:34:30PM +0200, Tomas Vondra wrote: > I looked at the long mode patch again, updated the commit message and > pushed it. I was wondering if long_mode should really be bool - > logically it is, but ZSTD_CCtx_setParameter() expects int. But I think > that's fine. Thanks! > I think that's all for PG16 in this patch series. If there's more we want to > do, it'll have to wait for PG17 - Yes > Justin, can you update and submit the patches that you think are relevant for > the next CF? Yeah. It sounds like a shiny new feature, but it's not totally clear if it's safe here or even how useful it is. (It might be like my patch for wal_compression=zstd:level, and Michael's for toast_compression=zstd, neither of which saw any support). Last year's basebackup thread had some interesting comments about safety of threads, although pg_dump's considerations may be different. The patch itself is trivial, so it'd be fine to wait until PG16 is released to get some experience. If someone else wanted to do that, it'd be fine with me. -- Justin
Commits
-
Support long distance matching for zstd compression
- 2820adf7755d 16.0 landed
-
pg_dump: Add support for zstd compression
- 84adc8e20f54 16.0 landed