Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 3476D633CCD for ; Thu, 12 Mar 2009 17:35:36 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 31959-10 for ; Thu, 12 Mar 2009 17:35:31 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from westnet.com (westnet.com [216.187.52.2]) by mail.postgresql.org (Postfix) with ESMTP id 72496633661 for ; Thu, 12 Mar 2009 17:35:33 -0300 (ADT) Received: from westnet.com (localhost [127.0.0.1]) by westnet.com (8.14.0/8.14.0) with ESMTP id n2CKZVHb018311; Thu, 12 Mar 2009 16:35:31 -0400 (EDT) Received: from localhost (gsmith@localhost) by westnet.com (8.14.0/8.13.2/Submit) with ESMTP id n2CKZVkh018308; Thu, 12 Mar 2009 16:35:31 -0400 (EDT) X-Authentication-Warning: westnet.com: gsmith owned process doing -bs Date: Thu, 12 Mar 2009 16:35:31 -0400 (EDT) From: Greg Smith X-X-Sender: gsmith@westnet.com To: "Jignesh K. Shah" cc: Scott Carey , Kevin Grittner , "pgsql-performance@postgresql.org" Subject: Re: Proposal of tunable fix for scalability of 8.4 In-Reply-To: <49B922C0.6050700@sun.com> Message-ID: References: <49B922C0.6050700@sun.com> User-Agent: Alpine 2.01 (GSO 1184 2008-12-16) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200903/141 X-Sequence-Number: 33063 On Thu, 12 Mar 2009, Jignesh K. Shah wrote: > As soon as I get more "cycles" I will try variations of it but it would > help if others can try it out in their own environments to see if it > helps their instances. What you should do next is see whether you can remove the bottleneck your test is running into via using a connection pooler. That's what I think most informed people would do were you to ask how to setup an optimal environment using PostgreSQL that aimed to serve thousands of clients. If that makes your bottleneck go away, that's what you should be recommending to customers who want to scale in this fashion too. If the bottleneck moves to somewhere else, that new hot spot might be one people care more about. Given that there are multiple good pooling solutions floating around already, it's hard to justify dumping coding and testing resources here if that makes the problem move somewhere else. It's great that you've identified an alternate scheduling approach that helps on your problematic test case, but you're a long ways from having a full model of how changes to the locking model impact other database workloads. As for the idea of doing something in this area for 8.4, there are a significant number of performance-related changes already committed for that version that deserve more focused testing during beta. You're way too late to throw another one into that already crowded area. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD