DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
	b=UNSQ+UuKUYp/nDoiL0r5PGkJujkqTedZjqVG0Lgz41UZ80cEIA3XtlqCcu4UTmL+6MHn4wlf1Ry2rxW7MbGmEE65lHan4bRwZ2FBXXv1jwGv1K+yXqL+SdQuVtVHQ/cdF84fzze/vf+yByoakiyvmTzaGMUQFbGWtyZxzbDKVGo=
Message-ID: <4772BEF8.2030509@enterprisedb.com>
Date: Wed, 26 Dec 2007 22:52:08 +0200
From: Heikki Linnakangas <heikki@enterprisedb.com>
User-Agent: Icedove 1.5.0.14pre (X11/20071020)
MIME-Version: 1.0
To: Jared Mauch <jared@puck.nether.net>
CC: pgsql-performance@postgresql.org
Subject: Re: pg_dump performance
References: <20071226202230.GA76524@puck.nether.net>
In-Reply-To: <20071226202230.GA76524@puck.nether.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Jared Mauch wrote:
> 	pg_dump is utilizing about 13% of the cpu and the
> corresponding postgres backend is at 100% cpu time.
> (multi-core, multi-cpu, lotsa ram, super-fast disk).
> ...
> 	Any tips on getting pg_dump (actually the backend) to perform 
> much closer to 500k/sec or more?  This would also aide me when I upgrade 
> pg versions and need to dump/restore with minimal downtime (as the data 
> never stops coming.. whee).

I would suggest running oprofile to see where the time is spent. There 
might be some simple optimizations that you could do at the source level 
that would help.

Where the time is spent depends a lot on the schema and data. For 
example, I profiled a pg_dump run on a benchmark database a while ago, 
and found that most of the time was spent in sprintf, formatting 
timestamp columns. If you have a lot of timestamp columns that might be 
the bottleneck for you as well, or something else.

Or if you can post the schema for the table you're dumping, maybe we can 
  make a more educated guess.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com