MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Date: Wed, 11 Mar 2009 23:48:44 -0400
From: "Jignesh K. Shah" <J.K.Shah@Sun.COM>
Subject: Re: Proposal of tunable fix for scalability of 8.4
In-reply-to: <29836.1236826066@sss.pgh.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Scott Carey <scott@richrelevance.com>,
	Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Message-id: <49B8861C.2000005@sun.com>
References: <C5DDBB25.3333%scott@richrelevance.com>
	<29836.1236826066@sss.pgh.pa.us>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)


Tom Lane wrote:
> Scott Carey <scott@richrelevance.com> writes:
>   
>> If there is enough lock contention and a common lock case is a short lived shared lock, it makes perfect sense sense.  Fewer readers are blocked waiting on writers at any given time.  Readers can 'cut' in line ahead of writers within a certain scope (only up to the number waiting at the time a shared lock is at the head of the queue).  Essentially this clumps up shared and exclusive locks into larger streaks, and allows for higher shared lock throughput.
>> Exclusive locks may be delayed, but will NOT be starved, since on the next iteration, a streak of exclusive locks will occur first in the list and they will all process before any more shared locks can go.
>>     
>
> That's a lot of sunny assertions without any shred of evidence behind
> them...
>
> The current LWLock behavior was arrived at over multiple iterations and
> is not lightly to be toyed with IMHO.  Especially not on the basis of
> one benchmark that does not reflect mainstream environments.
>
> Note that I'm not saying "no".  I'm saying that I want a lot more
> evidence *before* we go to the trouble of making this configurable
> and asking users to test it.
>
> 			regards, tom lane
>
>   
Fair enough..  Well I am now appealing  to all  who has a fairly decent 
sized hardware want to try it out  and see whether there are "gains", 
"no-changes" or "regressions" based on your workload. Also it will help 
if you report number of cpus when you respond back to help collect 
feedback.

Regards,
Jignesh

-- 
Jignesh Shah           http://blogs.sun.com/jkshah  			
The New Sun Microsystems,Inc   http://sun.com/postgresql