Received: from localhost (maia-2.hub.org [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id 808BA9F9F44 for ; Wed, 3 Jan 2007 13:58:27 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-new, port 10024) with ESMTP id 92005-03 for ; Wed, 3 Jan 2007 13:58:14 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from myemma.com (db1.e2ma.net [66.179.147.163]) by postgresql.org (Postfix) with ESMTP id 917849F938C for ; Wed, 3 Jan 2007 13:58:21 -0400 (AST) Received: from localhost (localhost.localdomain [127.0.0.1]) by myemma.com (Postfix) with ESMTP id 0705523CCE; Wed, 3 Jan 2007 11:58:21 -0600 (CST) Received: from myemma.com ([127.0.0.1]) by localhost (velma [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01561-04; Wed, 3 Jan 2007 11:58:20 -0600 (CST) Received: from [10.0.23.39] (unknown [209.149.59.218]) by myemma.com (Postfix) with ESMTP id 38F3B23CE7; Wed, 3 Jan 2007 11:58:20 -0600 (CST) Message-ID: <459BEEB8.5050405@myemma.com> Date: Wed, 03 Jan 2007 11:58:16 -0600 From: Erik Jones User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Tom Lane Cc: Guillaume Smet , pgsql-performance@postgresql.org Subject: Re: More 8.2 client issues (Was: [Slow dump?) References: <459AD5A8.7030102@myemma.com> <22512.1167779361@sss.pgh.pa.us> <459BD61C.3030202@myemma.com> <11617.1167841479@sss.pgh.pa.us> <459BDC98.8030008@myemma.com> <1d4e0c10701030850h78f19e74hfa7c25c01ded9a61@mail.gmail.com> <459BE4BB.4070601@myemma.com> <13359.1167844898@sss.pgh.pa.us> In-Reply-To: <13359.1167844898@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at myemma.com X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200701/42 X-Sequence-Number: 22643 Tom Lane wrote: > Erik Jones writes: > >> Guillaume Smet wrote: >> >>> Could you set log_min_duration_statement=0 on your server and enable >>> > > >> Heh, unfortunately, setting log_min_duration_statement=0 would be a >> total last resort as the last we counted (2 months ago) we were doing >> approximately 3 million transactions per hour. >> > > Do it just for the pg_dump: > > export PGOPTIONS="--log_min_duration_statement=0" > pg_dump ... > > I don't think that the regex issue explains pg_dump being slow, > unless perhaps you are making use of the table-selection switches? > That's a good idea, but first I'll still need to run it by my sysadmin wrt space -- our dump files are around 22GB when we can let them finish these days. We do have plans to move off of the dump to a snapshot backup strategy that will eventually lead to a PITR warm-standby setup but, first, we want to make sure we have a stable, fast, up-to-date server -- our web servers are still connecting to the db via 8.1.4 client libs as given what we've seen of the track record for 8.2. client libs on our setup, we're bit reticent to move the rest of the application over. While I wait to see what we can do about logging everything during the dump I'll probably build 8.2 on a remote linux machine and see how connecting via those tools compares. -- erik jones software development emma(r)