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
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
