Received: from localhost (maia-3.hub.org [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 70B919FB5CC for ; Thu, 19 Jul 2007 15:27:55 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 31099-03 for ; Thu, 19 Jul 2007 15:27:49 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from lists.commandprompt.com (host-254.commandprompt.net [207.173.203.254]) by postgresql.org (Postfix) with ESMTP id DA18E9FB5AE for ; Thu, 19 Jul 2007 15:27:51 -0300 (ADT) Received: from [192.168.1.137] (pool-71-111-20-15.ptldor.dsl-w.verizon.net [71.111.20.15]) (authenticated bits=0) by lists.commandprompt.com (8.13.7/8.13.6) with ESMTP id l6JIRoYF026996; Thu, 19 Jul 2007 11:27:50 -0700 Message-ID: <469FAD21.4020800@commandprompt.com> Date: Thu, 19 Jul 2007 11:27:45 -0700 From: "Joshua D. Drake" User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Alvaro Herrera CC: Tom Lane , Josh Berkus , pgsql-performance@postgresql.org Subject: Re: User concurrency thresholding: where do I look? References: <200707190828.59088.josh@agliodbs.com> <20070719154912.GG6538@alvh.no-ip.org> <200707190922.24497.josh@agliodbs.com> <12686.1184865938@sss.pgh.pa.us> <20070719173704.GA12084@alvh.no-ip.org> In-Reply-To: <20070719173704.GA12084@alvh.no-ip.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.90.3/3695/Wed Jul 18 04:34:50 2007 on projects.commandprompt.com X-Virus-Status: Clean X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-1.6 (lists.commandprompt.com [192.168.2.159]); Thu, 19 Jul 2007 11:27:51 -0700 (PDT) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.001 tagged_above=0 required=5 tests=BAYES_50=0.001 X-Spam-Level: X-Archive-Number: 200707/249 X-Sequence-Number: 25933 Alvaro Herrera wrote: > Tom Lane wrote: >> Josh Berkus writes: > So maybe this does not make much sense in normal operation, thus not > applicable to what Josh Berkus is reporting. > > However I was talking to Josh Drake yesterday and he told me that > pg_dump was spending some significant amount of time in LOCK TABLE when > there are lots of tables (say 300k). Less, 128k Joshua D. Drake >