pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Jim C. Nasby <jnasby@pervasive.com>
To: John Vincent <pgsql-performance@lusis.org>
Cc: Scott Marlowe <smarlowe@g2switchworks.com>
Cc: PGSQL Performance <pgsql-performance@postgresql.org>
Subject: Re: Performance of pg_dump on PGSQL 8.0
Date: Wed, 14 Jun 2006 16:25:08 -0500
Message-ID: <20060614212507.GR34196@pervasive.com> (raw)
In-Reply-To: <c841561b0606141418n6932ed5bwd54d6562ce78a415@mail.gmail.com>
References: <44902165.7020502@lusis.org>
	<1150303450.26538.9.camel@state.g2switchworks.com>
	<c841561b0606141111g9244024oc091c58ecf0e1d94@mail.gmail.com>
	<20060614211343.GP34196@pervasive.com>
	<c841561b0606141418n6932ed5bwd54d6562ce78a415@mail.gmail.com>

On Wed, Jun 14, 2006 at 05:18:14PM -0400, John Vincent wrote:
> On 6/14/06, Jim C. Nasby <jnasby@pervasive.com> wrote:
> >
> >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.
> 
> 
> But the custom format is still a binary backup, no?
 
I fail to see what that has to do with anything...

> 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).
> 
> 
> Unfortunately if we working with our current source box, the 1 CPU is
> already the bottleneck in regards to compression. If I run the pg_dump from
> the remote server though, I might be okay.

Oh, right, forgot about that. Yeah, your best bet could be to use an
external machine for the dump.
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461



view thread (14+ messages)  latest in thread

Message-ID: <20060614212507.GR34196@pervasive.com>
Permalink:  ../20060614212507.GR34196@pervasive.com/
Also on:    postgresql.org/message-id/20060614212507.GR34196@pervasive.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: jnasby@pervasive.com, pgsql-performance@lusis.org, smarlowe@g2switchworks.com
  Subject: Re: Performance of pg_dump on PGSQL 8.0
  In-Reply-To: <20060614212507.GR34196@pervasive.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox