X-Original-To: pgsql-performance-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 0B5859FA5C8 for ; Wed, 14 Jun 2006 18:13:55 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 73330-04 for ; Wed, 14 Jun 2006 18:13:48 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id DD7869FA3D7 for ; Wed, 14 Jun 2006 18:13:48 -0300 (ADT) Received: by noel.decibel.org (Postfix, from userid 1001) id 98B6656437; Wed, 14 Jun 2006 16:13:46 -0500 (CDT) Received: (hashcash-sendmail, from uid 1001); Wed, 14 Jun 2006 16:13:44 -0500 Date: Wed, 14 Jun 2006 16:13:44 -0500 From: "Jim C. Nasby" To: John Vincent Cc: Scott Marlowe , PGSQL Performance Subject: Re: Performance of pg_dump on PGSQL 8.0 Message-ID: <20060614211343.GP34196@pervasive.com> References: <44902165.7020502@lusis.org> <1150303450.26538.9.camel@state.g2switchworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 6.0-RELEASE-p4 amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.11 X-Hashcash: 1:20:060614:pgsql-performance@lusis.org::7FJVWxx+h6cCJsmX:0000000000 0000000000000000000000002xHW X-Hashcash: 1:20:060614:smarlowe@g2switchworks.com::D3DvzD1fGQ2wra7m:00000000000 0000000000000000000000008QUL X-Hashcash: 1:20:060614:pgsql-performance@postgresql.org::KhaUZhd4/ckvfAMs:00000 00000000000000000000000037+9 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200606/273 X-Sequence-Number: 19630 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@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461