| From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
|---|---|
| To: | John Vincent <pgsql-performance(at)lusis(dot)org> |
| Cc: | Scott Marlowe <smarlowe(at)g2switchworks(dot)com>, PGSQL Performance <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Performance of pg_dump on PGSQL 8.0 |
| Date: | 2006-06-14 21:13:44 |
| Message-ID: | 20060614211343.GP34196@pervasive.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Wed, Jun 14, 2006 at 02:11:19PM -0400, John Vincent wrote:
> Out of curiosity, does anyone have any idea what the ratio of actual
> datasize to backup size is if I use the custom format with -Z 0 compression
> or the tar format?
-Z 0 should mean no compression.
Something you can try is piping the output of pg_dump to gzip/bzip2. On
some OSes, that will let you utilize 1 CPU for just the compression. If
you wanted to get even fancier, there is a parallelized version of bzip2
out there, which should let you use all your CPUs.
Or if you don't care about disk IO bandwidth, just compress after the
fact (though, that could just put you in a situation where pg_dump
becomes bandwidth constrained).
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
| From | Date | Subject | |
|---|---|---|---|
| Next Message | John Vincent | 2006-06-14 21:16:19 | Re: Performance of pg_dump on PGSQL 8.0 |
| Previous Message | Scott Marlowe | 2006-06-14 21:03:35 | Re: Performance of pg_dump on PGSQL 8.0 |