Re: Is there anything special about pg_dump's compression? - Mailing list pgsql-sql

From Tom Lane
Subject Re: Is there anything special about pg_dump's compression?
Date
Msg-id 26036.1195190971@sss.pgh.pa.us
Whole thread Raw
In response to Re: Is there anything special about pg_dump's compression?  (Jean-David Beyer <jeandavid8@verizon.net>)
Responses Re: Is there anything special about pg_dump's compression?  (Jean-David Beyer <jeandavid8@verizon.net>)
List pgsql-sql
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


pgsql-sql by date:

Previous
From: Jean-David Beyer
Date:
Subject: Re: Is there anything special about pg_dump's compression?
Next
From: "Bart Degryse"
Date:
Subject: Re: trap for any exception