Обсуждение: Feature Request: bzip2 support in pg_dump, pg_restore
Hi, dear postgres developers,
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?
Regards,
Daniel Migowski
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?
Regards,
Daniel Migowski
--
IKOffice UNTERNEHMENSSOFTWARE | IKOffice GmbH | Daniel Migowski | |
Mail: | dmigowski@ikoffice.de | ||
Nordstrasse 10 | Tel.: | +49 (0)441 21 98 89 52 | |
26135 Oldenburg | Fax.: | +49 (0)441 21 98 89 55 | |
http://www.ikoffice.de | Mob.: | +49 (0)176 22 31 20 76 | |
Geschäftsführer: | Ingo Kuhlmann, Daniel Migowski | ||
Amtsgericht Oldenburg: | HRB 201467 | ||
Steuernummer: | 64/211/01864 |
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:
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.
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