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 911469FA5C8 for ; Wed, 14 Jun 2006 18:25:16 -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 73287-09 for ; Wed, 14 Jun 2006 18:25:10 -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 0F6B19FA3D7 for ; Wed, 14 Jun 2006 18:25:10 -0300 (ADT) Received: by noel.decibel.org (Postfix, from userid 1001) id CF26756440; Wed, 14 Jun 2006 16:25:08 -0500 (CDT) Received: (hashcash-sendmail, from uid 1001); Wed, 14 Jun 2006 16:25:08 -0500 Date: Wed, 14 Jun 2006 16:25:08 -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: <20060614212507.GR34196@pervasive.com> References: <44902165.7020502@lusis.org> <1150303450.26538.9.camel@state.g2switchworks.com> <20060614211343.GP34196@pervasive.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::AGsL0aMBpg8l5LQh:0000000000 0000000000000000000000000KJJ X-Hashcash: 1:20:060614:smarlowe@g2switchworks.com::g9uWbu/s0D/1MGpp:00000000000 0000000000000000000000002984 X-Hashcash: 1:20:060614:pgsql-performance@postgresql.org::Iad7pH4EnBEbstzW:00000 00000000000000000000000029ri X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200606/276 X-Sequence-Number: 19633 On Wed, Jun 14, 2006 at 05:18:14PM -0400, John Vincent wrote: > On 6/14/06, Jim C. Nasby 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