pg_dump -Fd and compression level

From: Marc Mamin <M(dot)Mamin(at)intershop(dot)de>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: "'michael(dot)paquier(at)gmail(dot)com'" <michael(dot)paquier(at)gmail(dot)com>
Subject: pg_dump -Fd and compression level
Date: 2015-07-24 06:52:58
Message-ID: B6F6FD62F2624C4C9916AC0175D56D8828C17D8E@jenmbs01.ad.intershop.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello,

After our last upgrade, we've noticed a 10-20% size increase of our dump size.
This comes from our backup scripts were pg_dump was called without setting -Z

So it seems, that this fix did modify the default compression to use:
http://michael.otacoo.com/postgresql-2/pg_dump-directory-format-compression/

not sure if this is expected or if this commit accidently changed the default compression, setting it too low.

moreover, the doc is somewhat unclear here as it mentions all formats but the directory one:

-Z 0..9
--compress=0..9

Specify the compression level to use. Zero means no compression.
For the custom archive format, this specifies compression of individual
table-data segments, and the default is to compress at a moderate level.
For plain text output, setting a nonzero compression level causes the entire
output file to be compressed, as though it had been fed through gzip;
but the default is not to compress.
The tar archive format currently does not support compression at all.

shouldn't that be changed to

- For the custom archive format
+ For the directory and custom archive formats


best regards,

Marc Mamin

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2015-07-24 06:53:49 Re: Improving replay of XLOG_BTREE_VACUUM records
Previous Message Heikki Linnakangas 2015-07-24 06:27:13 Re: WAL logging problem in 9.4.3?