Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id CC9AB635378 for ; Wed, 11 Mar 2009 23:20:44 -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 65753-09 for ; Wed, 11 Mar 2009 23:20:32 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by mail.postgresql.org (Postfix) with ESMTP id 78EBB6348E1 for ; Wed, 11 Mar 2009 23:20:24 -0300 (ADT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2C2KMYH015562 for ; Thu, 12 Mar 2009 02:20:22 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; format=flowed; charset=ISO-8859-1 Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KGD00J00FTKF900@mail-amer.sun.com> for pgsql-performance@postgresql.org; Wed, 11 Mar 2009 20:20:22 -0600 (MDT) Received: from Macintosh-8.local ([unknown] [96.237.55.23]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KGD002N5FTRGQD0@mail-amer.sun.com>; Wed, 11 Mar 2009 20:20:20 -0600 (MDT) Date: Wed, 11 Mar 2009 22:20:17 -0400 From: "Jignesh K. Shah" Subject: Re: Proposal of tunable fix for scalability of 8.4 In-reply-to: <29080.1236821556@sss.pgh.pa.us> To: Tom Lane Cc: Kevin Grittner , pgsql-performance@postgresql.org Message-id: <49B87161.10201@sun.com> References: <49B824DD.7090302@sun.com> <49B7F470.EE98.0025.0@wicourts.gov> <29080.1236821556@sss.pgh.pa.us> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200903/113 X-Sequence-Number: 33035 Tom Lane wrote: > "Kevin Grittner" writes: > >> I'm wondering about the testing methodology. >> > > Me too. This test case seems much too far away from real world use > to justify diddling low-level locking behavior; especially a change > that is obviously likely to have very negative effects in other > scenarios. In particular, I think it would lead to complete starvation > of would-be exclusive lockers in the face of competition from a steady > stream of shared lockers. AFAIR the existing behavior was designed > to reduce the odds of that, not for any other purpose. > > regards, tom lane > > Hi Tom, The test case is not that far fetched from real world.. Plus if you read my proposal I clearly mention a tunable for it so that we can set and hence obviously not impact 99% of the people who don't care about it but still allow the flexibility of the 1% of the people who do care about scalability when they go on bigger system. The fact that it is a tunable (and obviously not the default way) there is no impact to existing behavior. My test case clearly shows that Exclusive lockers ARE benefited from it otherwise I would have not seen the huge impact on throughput. A tunable does not impact existing behavior but adds flexibility for those using PostgreSQL on high end systems. Plus doing it the tunable way on PostgreSQL 8.4 will convince many people that I know to quickly adopt PostgreSQL 8.4 just because of the benefit it brings on systems with many cpus/cores/threads. All I am requesting is for the beta to have that tunable. Its not hard, people can then quickly try default (off) or on or as Scott Carey mentioned a more flexible of default, all or a fixed integer number (for people to experiment). Regards, Jignesh -- Jignesh Shah http://blogs.sun.com/jkshah The New Sun Microsystems,Inc http://sun.com/postgresql