Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 3F747633448 for ; Fri, 13 Mar 2009 10:54:19 -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 78033-02 for ; Fri, 13 Mar 2009 10:54:09 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by mail.postgresql.org (Postfix) with SMTP id B06F46322EB for ; Fri, 13 Mar 2009 10:54:13 -0300 (ADT) Received: from source ([64.233.182.187]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKSbplhBM+aKzf0mL+RnqPnv5BKH4NShca@postini.com; Fri, 13 Mar 2009 06:54:13 PDT Received: by nf-out-0910.google.com with SMTP id c10so787684nfd.4 for ; Fri, 13 Mar 2009 06:54:11 -0700 (PDT) Received: by 10.216.37.212 with SMTP id y62mr617763wea.5.1236952451372; Fri, 13 Mar 2009 06:54:11 -0700 (PDT) Received: from oxford.xeocode.com.enterprisedb.com ([82.16.16.210]) by mx.google.com with ESMTPS id d24sm3192740nfh.43.2009.03.13.06.54.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Mar 2009 06:54:10 -0700 (PDT) To: "Jignesh K. Shah" Cc: Scott Carey , Tom Lane , Kevin Grittner , "pgsql-performance\@postgresql.org" Subject: Re: Proposal of tunable fix for scalability of 8.4 In-Reply-To: <49BA6175.4060809@sun.com> (Jignesh K. Shah's message of "Fri\, 13 Mar 2009 09\:36\:53 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-Draft-From: ("nnimap+imap.gmail.com:PG" 112944) References: <49BA53CF.4020702@sun.com> <871vt1609r.fsf@oxford.xeocode.com> <49BA6175.4060809@sun.com> From: Gregory Stark Organization: EnterpriseDB Date: Fri, 13 Mar 2009 13:54:09 +0000 Message-ID: <87r6114jge.fsf@oxford.xeocode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200903/157 X-Sequence-Number: 33079 "Jignesh K. Shah" writes: > Gregory Stark wrote: >> Keep in mind when you do this that it's not interesting to test a number of >> connections much larger than the number of processors you have. Once the >> system reaches 100% cpu usage it would be a misconfigured connection pooler >> that kept more than that number of connections open. > > Greg, Unfortuately the problem is that.. I am trying to reach 100% CPU which > I cannot and hence I am increasing the user count :-) The effect of increasing the number of users with a connection pooler would be to decrease the 200ms sleep time to 0. This is all assuming the idle time is *between* transactions. If you have idle time in the middle of transactions things become a lot more tricky. I think we are missing something to deal with that use case. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support!