Re: zstd compression for pg_dump
Jacob Champion <jchampion@timescale.com>
From: Jacob Champion <jchampion@timescale.com>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: pgsql-hackers@postgresql.org, gkokolatos@pm.me, Michael Paquier <michael@paquier.xyz>,
Tomas Vondra <tomas.vondra@enterprisedb.com>, 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-03-08T18:59:23Z
Lists: pgsql-hackers
On Sat, Mar 4, 2023 at 8:57 AM Justin Pryzby <pryzby@telsasoft.com> wrote: > pryzbyj=# CREATE TABLE t1 AS SELECT i,array_agg(j) FROM generate_series(1,444)i,generate_series(1,99999)j GROUP BY 1; > $ ./src/bin/pg_dump/pg_dump -d pryzbyj -Fc -Z zstd:long=1 |wc -c > 82023 > $ ./src/bin/pg_dump/pg_dump -d pryzbyj -Fc -Z zstd:long=0 |wc -c > 1048267 Nice! I did some smoke testing against zstd's GitHub release on Windows. To build against it, I had to construct an import library, and put that and the DLL into the `lib` folder expected by the MSVC scripts... which makes me wonder if I've chosen a harder way than necessary? Parallel zstd dumps seem to work as expected, in that the resulting pg_restore output is identical to uncompressed dumps and nothing explodes. I haven't inspected the threading implementation for safety yet, as you mentioned. And I still wasn't able to test :workers, since it looks like the official libzstd for Windows isn't built for multithreading. That'll be another day's project. --Jacob
Commits
-
Support long distance matching for zstd compression
- 2820adf7755d 16.0 landed
-
pg_dump: Add support for zstd compression
- 84adc8e20f54 16.0 landed