On Mon, Aug 3, 2009 at 2:56 PM, Tom Lane<t...@sss.pgh.pa.us> wrote: > I don't see anything very contradictory here. What you're demonstrating > is that it's nice to be able to throw a third CPU at the compression > part of the problem. That's likely to remain true if we shift to a > different compression algorithm. I suspect if you substituted lzo for > gzip in the third case, the picture wouldn't change very much.
lzo is much, much, (much) faster than zlib. Note, I've tried several times to contact the author to get clarification on licensing terms and have been unable to get a response. [r...@devdb merlin]# time lzop -c dump.sql > /dev/null real 0m16.683s user 0m15.573s sys 0m0.939s [r...@devdb merlin]# time gzip -c dump.sql > /dev/null real 3m43.090s user 3m41.471s sys 0m1.036s merlin -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
