On Mon, Aug 3, 2009 at 2:56 PM, Tom Lane<tgl@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.
[root@devdb merlin]# time lzop -c dump.sql > /dev/null
real 0m16.683s
user 0m15.573s
sys 0m0.939s
[root@devdb merlin]# time gzip -c dump.sql > /dev/null
real 3m43.090s
user 3m41.471s
sys 0m1.036s
merlin
