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 E29E99FA5D8 for ; Wed, 14 Jun 2006 12:52:00 -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 33615-02 for ; Wed, 14 Jun 2006 12:51:49 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 4575D9FA5FC for ; Wed, 14 Jun 2006 12:51:50 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id k5EFplJV026781; Wed, 14 Jun 2006 11:51:47 -0400 (EDT) To: pgsql-performance@lusis.org cc: "PGSQL Performance" Subject: Re: Performance of pg_dump on PGSQL 8.0 In-reply-to: <44902165.7020502@lusis.org> References: <44902165.7020502@lusis.org> Comments: In-reply-to "John E. Vincent" message dated "Wed, 14 Jun 2006 10:47:01 -0400" Date: Wed, 14 Jun 2006 11:51:47 -0400 Message-ID: <26780.1150300307@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200606/257 X-Sequence-Number: 19614 "John E. Vincent" writes: > I've watched the backup process and I/O is not a problem. Memory isn't a > problem either. It seems that we're CPU bound but NOT in I/O wait. Is it the pg_dump process, or the connected backend, that's chewing the bulk of the CPU time? (This should be pretty obvious in "top".) If it's the pg_dump process, the bulk of the CPU time is likely going into compression --- you might consider backing off the compression level, perhaps --compress=1 or even 0 if size of the dump file isn't a big concern. Another possibility if your LAN is reasonably fast is to run pg_dump on a different machine, so that you can put two CPUs to work. regards, tom lane