Re: pg_dump -Fd and compression level - Mailing list pgsql-hackers

From Marc Mamin
Subject Re: pg_dump -Fd and compression level
Date
Msg-id B6F6FD62F2624C4C9916AC0175D56D8828C18102@jenmbs01.ad.intershop.net
Whole thread Raw
In response to Re: pg_dump -Fd and compression level  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_dump -Fd and compression level  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers

>Andrew Dunstan <andrew@dunslane.net> writes:
>> Hmm. Yeah. It looks like commit a7ad5cf0cfcfab8418000d652fa4f0c6ad6c8911
>> changed from using the default compression for libz to using the
>> compression set in pg_dump options, which defaults to 0. This actually
>> seems like the right thing to do, but it certainly should have been
>> called out much more forcefully in release notes, and arguably should
>> not have been changed in stable releases. Not sure what we do about it now.

really 0? wouldn't that mean no compression at all?

>I don't think we realized that we were changing the default behavior.
>Still, it's clearly a bug fix, so I'm disinclined to revert it now.
>
>                        regards, tom lane

Sure, but at least the doc should be modified as it suggests that a higher compression is used:

"the default is to compress at a moderate level"
=>
"the default is to compress at the lowest level"

And maybe a quick notice for planet Postgres to highlight the modification of the default behavior.
(I' haven't a blog myself ...)

IMHO a slightly higher default would help spare some hardware out there...

regards,
Marc Mamin


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: [PROPOSAL] VACUUM Progress Checker.
Next
From: Noah Misch
Date:
Subject: Re: Supporting TAP tests with MSVC and Windows