To: Jean-David Beyer <jeandavid8@verizon.net>
cc: pgsql-sql@postgresql.org
Subject: Re: Is there anything special about pg_dump's compression? 
In-reply-to: <473D2408.8060406@verizon.net> 
References: <473C6E58.5010102@verizon.net>
	<20071115161138.GI20228@crankycanuck.ca>
	<473D2408.8060406@verizon.net>
Comments: In-reply-to Jean-David Beyer <jeandavid8@verizon.net>
	message dated "Fri, 16 Nov 2007 00:00:56 -0500"
Date: Fri, 16 Nov 2007 00:29:31 -0500
Message-ID: <26036.1195190971@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Jean-David Beyer <jeandavid8@verizon.net> writes:
> I turned the software compression off. It took:
> 524487428 bytes (524 MB) copied, 125.394 seconds, 4.2 MB/s

> When I let the software compression run, it uses only 30 MBytes. So whatever
> compression it uses is very good on this kind of data.
> 29810260 bytes (30 MB) copied, 123.145 seconds, 242 kB/s

Seems to me the conclusion is obvious: you are writing about the same
number of bits to physical tape either way.  The physical tape speed is
surely the real bottleneck here, and the fact that the total elapsed
time is about the same both ways proves that about the same number of
bits went onto tape both ways.

The quoted MB and MB/s numbers are not too comparable because they are
before and after compression respectively.

The software compression seems to be a percent or two better than the
hardware's compression, but that's not enough to worry about really.
What you should ask yourself is whether you have other uses for the main
CPU's cycles during the time you're taking backups.  If so, offload the
compression cycles onto the tape hardware.  If not, you might as well
gain the one or two percent win.

			regards, tom lane