Feature Request: bzip2 support in pg_dump, pg_restore

Heyho!

On Friday 13 August 2010 10.57:13 Daniel Migowski wrote:

A small investigation showed to me that bzip2 compressed sql files take
only 60% of the space of gz compressed files.

But bzip2 is very slow. I think if there should be changes to the data
compression, xz is probably the future. xz is said to be similar to bzip2
in terms of compression ratio, but much faster.

cheers
-- vbi

--
And those meanies used what we said to you and they misconstrued it to
mean what we said, and that's so unfair.
-- SCO lawyers about IBM (paraphrased - groklaw)

pg_dumpall | bzip2 > mydump.txt.bz2

bunzip2 -kc mydump.txt.bz2 | bin/psql template1

--
Scott Ribe
scott_ribe@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice

Daniel Migowski wrote:

A small investigation showed to me that bzip2 compressed sql files
take only 60% of the space of gz compressed files. Since bzip2 is
fairly common today, could one add an option to pg_dump and pg_restore
supporting this compression type in their custom format? Or do the
PostgreSQL folks prefer no to do that regarding backwards compatibility?

http://wiki.postgresql.org/wiki/Developer_FAQ#Why_aren.27t_there_more_compression_options_when_dumping_tables.3F
now has a first round answer to this topic, one that addresses the
things that pop up every time this discussion is raised. There are
speed, code quality, code license, and patent issues all making this
much harder to change than is obvious at first.

--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.us

Greg Smith <greg@2ndquadrant.com> writes:

Daniel Migowski wrote:

A small investigation showed to me that bzip2 compressed sql files
take only 60% of the space of gz compressed files. Since bzip2 is
fairly common today, could one add an option to pg_dump and pg_restore
supporting this compression type in their custom format? Or do the
PostgreSQL folks prefer no to do that regarding backwards compatibility?

http://wiki.postgresql.org/wiki/Developer_FAQ#Why_aren.27t_there_more_compression_options_when_dumping_tables.3F
now has a first round answer to this topic, one that addresses the
things that pop up every time this discussion is raised. There are
speed, code quality, code license, and patent issues all making this
much harder to change than is obvious at first.

Looks good. I added the point that pg_dump output has to be readable
far into the future, so conservatism in what we support is a good thing.

regards, tom lane