Robert Haas wrote:
On Fri, Mar 20, 2009 at 7:39 PM, Jignesh K. Shah <J.K.Shah@xxxxxxx> wrote:
Alvaro Herrera wrote:
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
I'm confused. Is a process waiting for an LWLock is in a runnable
state? I thought we went to sleep on a semaphore.
...Robert
If you check the code
http://doxygen.postgresql.org/lwlock_8c-source.html#l00451
Semaphore lock can wake up but then it needs to confirm !proc->lwWaiting
which can be TRUE if you have not been "Waked up"
then it increase the extraWaits count and go back to PGSemaphoreLock
.. What my patch gives the flexibility with sequential X wakeups that it
can still exit and check for getting the exclusive lock and if not add
back to the queue. My theory is when it is already on CPU running makes
sense to check for the lock if another exclusive is running since the
chances are that it has completed within few cycles is very high.. and
the improvement that I see leads to that inference. Otherwise if
lwWaiting is TRUE then it does not even check if the lock is available
or not and just goes back and waits for the next chance.. This is the
part that gets the benefit of my patch.
-Jignesh
--
Jignesh Shah http://blogs.sun.com/jkshah
The New Sun Microsystems,Inc http://sun.com/postgresql
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
