Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id F0E0A632959 for ; Wed, 18 Mar 2009 18:16:09 -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 93369-07 for ; Wed, 18 Mar 2009 18:16:02 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from EXHUB018-1.exch018.msoutlookonline.net (exhub018-1.exch018.msoutlookonline.net [64.78.17.16]) by mail.postgresql.org (Postfix) with ESMTP id 8785A634BD1 for ; Wed, 18 Mar 2009 18:16:03 -0300 (ADT) Received: from EXVMBX018-1.exch018.msoutlookonline.net ([64.78.17.47]) by EXHUB018-1.exch018.msoutlookonline.net ([64.78.17.16]) with mapi; Wed, 18 Mar 2009 14:16:01 -0700 From: Scott Carey To: Gregory Stark , "Jignesh K. Shah" CC: Simon Riggs , Tom Lane , Kevin Grittner , "pgsql-performance@postgresql.org" Date: Wed, 18 Mar 2009 14:16:01 -0700 Subject: Re: Proposal of tunable fix for scalability of 8.4 Thread-Topic: [PERFORM] Proposal of tunable fix for scalability of 8.4 Thread-Index: Acmnvh6+WrIbuwvTTN+V69VdtfB+agAUJ43M Message-ID: In-Reply-To: <87iqm7f4gd.fsf@oxford.xeocode.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=AWL=0.000 X-Spam-Level: X-Archive-Number: 200903/257 X-Sequence-Number: 33179 On 3/18/09 4:36 AM, "Gregory Stark" wrote: >=20 >=20 > "Jignesh K. Shah" writes: >=20 >> In next couple of weeks I plan to test the patch on a different x64 base= d >> system to do a sanity testing on lower number of cores and also try out = other >> workloads ... >=20 > I'm actually more interested in the large number of cores but fewer proce= sses > and lower max_connections. If you set max_connections to 64 and eliminate= the > wait time you should, in theory, be able to get 100% cpu usage. It would = be > very interesting to track down the contention which is preventing that. My previous calculation in this thread showed that even at 0 wait time, the client seems to introduce ~3ms wait time overhead on average. So it takes close to 128 threads in each test to stop the linear scaling since the average processing time seems to be about ~3ms. Either that, or the tests actually are running on a system capable of 128 threads. >=20 > -- > Gregory Stark > EnterpriseDB http://www.enterprisedb.com > Ask me about EnterpriseDB's PostGIS support! >=20 > - > Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org= ) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance >=20