MIME-version: 1.0
Content-transfer-encoding: 8BIT
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Date: Fri, 20 Mar 2009 19:39:13 -0400
From: "Jignesh K. Shah" <J.K.Shah@Sun.COM>
Subject: Re: Proposal of tunable fix for scalability of 8.4
In-reply-to: <20090320220513.GS8313@alvh.no-ip.org>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Scott Carey <scott@richrelevance.com>,
 Robert Haas <robertmhaas@gmail.com>,
	Greg Smith <gsmith@gregsmith.com>,
	Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Message-id: <49C42921.8050508@sun.com>
References: <603c8f070903191349p5e8fb00as2816581d584fcefd@mail.gmail.com>
	<BDFBB77C9E07BE4A984DAAE981D19F961AEE7AFBB5@EXVMBX018-1.exch018.msoutlookonline.net>
	<20090320154601.GC8313@alvh.no-ip.org>
	<20090320215813.GR8313@alvh.no-ip.org>
	<20090320220513.GS8313@alvh.no-ip.org>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)


Alvaro Herrera wrote:
> Alvaro Herrera escribió:
>
>   
>> So Simon's correct.
>>     
>
> And perhaps this explains why Jignesh is measuring an improvement on his
> benchmark.  Perhaps an useful experiment would be to turn this behavior
> off and compare performance.  This lack of measurement is probably the
> cause that the suggested patch to fix it was never applied.
>
> The patch is here
> http://archives.postgresql.org//pgsql-hackers/2004-11/msg00935.php
>
>   
One of the reasons why my patch helps is it keeps this check intact but 
allows other exclusive Wake up.. Now what PostgreSQL calls "Wakes" is  
in reality just makes a variable indicating wake up and not really 
signalling a process to wake up. This is a key point to note. So when 
the process wanting the exclusive fights the OS Scheduling policy to 
finally get time on the CPU then it   check the value to see if it is 
allowed to wake up and potentially due the delay between when some other 
process marked that process "Waked up" and when the process check the 
value "Waked up"  it is likely that the lock is free (or other exclusive 
process had the lock, did its work and releaed it ).  Over it works well 
since it lives within the logical semantics of the locks but just uses 
various differences in OS scheduling and inherent delays in the system.

It actually makes sense if the process is on CPU wanting exclusive while 
someone else is doing exclusive, let them try getting the lock rather 
than preventing it from trying. The Lock semantic will make sure that 
they don't issue exclusive locks to two process so there is no issue 
with it trying.

It's late in Friday so I wont be able to explain it better but when load 
is heavy, getting on CPU is an achievement, let them try an exclusive 
lock while they are already there.

Try it!!

-Jignesh