Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 0F6E0633623 for ; Mon, 16 Mar 2009 12:48:45 -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 61383-06 for ; Mon, 16 Mar 2009 12:48:42 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from gwmta.wicourts.gov (gwmta.wicourts.gov [165.219.244.99]) by mail.postgresql.org (Postfix) with ESMTP id 58C846334B4 for ; Mon, 16 Mar 2009 12:48:40 -0300 (ADT) Received: from Courts-MTA by gwmta.wicourts.gov with Novell_GroupWise; Mon, 16 Mar 2009 10:48:37 -0500 Message-Id: <49BE2E80.EE98.0025.0@wicourts.gov> X-Mailer: Novell GroupWise Internet Agent 7.0.3 Date: Mon, 16 Mar 2009 10:48:32 -0500 From: "Kevin Grittner" To: Cc: "Robert Haas" , "Greg Smith" , "pgsql-performance@postgresql.org" , "Scott Carey" , "Tom Lane" , "Jignesh K. Shah" Subject: Re: Proposal of tunable fix for scalability of 8.4 References: <603c8f070903121829r31cf1472ha9876e5c480a542e@mail.gmail.com><603c8f070903121829r31cf1472ha9876e5c480a542e@mail.gmail.com> <12292.1236964604@sss.pgh.pa.us> <49BA5960.EE98.0025.0@wicourts.gov> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200903/208 X-Sequence-Number: 33130 wrote: > On Fri, 13 Mar 2009, Kevin Grittner wrote: >> If all data access is in RAM, why can't 80 processes >> keep 64 threads (on 8 processors) busy? Does anybody else think >> that's an interesting question, or am I off in left field here? > > I don't think that anyone is arguing that it's not intersting, but I > also think that complete dismissal of the existing test case is also > wrong. Right, I just think this point in the test might give more targeted results. When you've got many more times the number of processes than processors, of course processes will be held up. It seems to me that this is the point where the real issues are least likely to get lost in the noise. It also might point out delays from the clients which would help in interpreting the results farther down the list. One more reason this point is an interesting one is that it is one that gets *worse* with the suggested patch, if only by half a percent. Without: 600: 80: Medium Throughput: 82632.000 Avg Medium Resp: 0.005 with: 600: 80: Medium Throughput: 82241.000 Avg Medium Resp: 0.005 -Kevin