Re: TODO: fix priority of ordering of read and write light-weight locks

Jeff Janes <jeff.janes@gmail.com> writes:
> The wiki todo has the topic "Fix priority ordering of read and write
> light-weight locks" and
> references http://archives.postgresql.org/pgsql-hackers/2004-11/msg00893.php
> (lwlocks and starvation)

> Having read the referenced discussion, I'm trying to figure out what
> remains to be done.

AFAIR that patch hasn't been applied because nobody's demonstrated
an overall win from changing it.  It's not only a matter of showing
an improvement for some one workload, but providing some confidence
that no other case gets a lot worse.  If you go back to circa 2000
or 2001 to see the previous iteration of tweaking the lock algorithms,
you'll see that we found that it's important to avoid unnecessary
trips through the kernel scheduler.  If we force a incoming shared
requestor to block, there's a very real chance that the overhead from
descheduling and later rescheduling him will mean a net performance
degradation regardless of any other benefits.  As against this there's
the risk of long-term starvation of an exclusive requestor --- but
there is little if any evidence that that's a serious problem in
practice.

Just to make things more interesting, the context has changed a lot
since 2000-2001 --- far more people have multi-CPU machines now.
So it's possible the tradeoffs have changed.

> Since lwlock covers a rather heterogeneous bunch of lock purposes, it
> seems unlikely to me any one strategy is going to be applicable to all
> of those purposes if extreme optimization is what we are after .  How
> much are we willing to sacrifice modularity and abstraction in order
> to get a little extra performance out of things protected by lwlock?

My answer is "not a lot, unless it's a *lot* of extra performance".
We've talked sometimes about having more than one type of LWLock
to address different scheduling needs, but nobody's come up with
evidence that that'd really be helpful.

Also, did you see this thread:
http://archives.postgresql.org/pgsql-performance/2009-03/msg00104.php
That proposal was bounced because it seemed likely to hurt in a
much wider set of cases than it helped (see extra-scheduling-overhead
argument).  But I'd still be interested to see an unbiased analysis
of what was going on in the case where it seemed to help.
        regards, tom lane