Re: pg_dump -Fd and compression level

Поиск
Список
Период
Сортировка
От Marc Mamin
Тема Re: pg_dump -Fd and compression level
Дата
Msg-id B6F6FD62F2624C4C9916AC0175D56D8828C18102@jenmbs01.ad.intershop.net
обсуждение исходный текст
Ответ на Re: pg_dump -Fd and compression level  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pg_dump -Fd and compression level  (Andrew Dunstan <andrew@dunslane.net>)
Список 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 по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: [PROPOSAL] VACUUM Progress Checker.
Следующее
От: Noah Misch
Дата:
Сообщение: Re: Supporting TAP tests with MSVC and Windows