Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id B5AF31EB83EA for ; Thu, 23 Feb 2012 13:08:52 -0400 (AST) Received: from gwmta.wicourts.gov ([165.219.244.99] helo=gw.wicourts.gov) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1S0c9z-0000kn-QQ for pgsql-admin@postgresql.org; Thu, 23 Feb 2012 17:08:52 +0000 Received: from Courts-MTA by gw.wicourts.gov with Novell_GroupWise; Thu, 23 Feb 2012 11:08:32 -0600 Message-Id: <4F461E2D0200002500045AC3@gw.wicourts.gov> X-Mailer: Novell GroupWise Internet Agent 8.0.2 Date: Thu, 23 Feb 2012 11:08:29 -0600 From: "Kevin Grittner" To: "Michael Monnerie" , Subject: Re: speedup pg_dumpall References: <2829256.7Mb1lcLYlD@saturn> In-Reply-To: <2829256.7Mb1lcLYlD@saturn> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Pg-Spam-Score: -4.2 (----) X-Archive-Number: 201202/93 X-Sequence-Number: 39153 Michael Monnerie wrote: > What can I do to improve pg_dump performance? I can't help wondering why you're running it. For routine backups it is generally not your best option in PostgreSQL. PITR or warm standby are generally more useful for routine backups of any database big enough to worry about run time. For my purposes, pg_dump is mostly useful for dumping schema as SQL statements or dumping data from individual tables. Prior to the availability of pg_upgrade our main use was for upgrades from one major release to another, but I now see it as a pretty narrow niche utility -- at least for my shop. -Kevin