Re: LWLOCK_STATS

On Jan 6, 2012, at 8:40 PM, Robert Haas wrote:
>>>  Somewhat depressingly,
>>> virtually all of the interesting activity still centers around the
>>> same three locks that were problematic back then, which means that -
>>> although overall performance has improved quite a bit - we've not
>>> really delivered any knockout punches.  Here are the perpetrators:
>> 
>> I don't think that is depressing at all.  Certain locks needs to exist
>> to protect certain things, and a benchmark which tests those things is
>> going to take those locks rather than some other set of locks.  X
>> times faster is still X times faster, even if the bottleneck hasn't
>> move to some other part of the code.
> 
> True.  What I don't like is: I think we've really only pushed the
> bottleneck out a few cores.  Throw a 64-core machine at it and we're
> going to have all these same problems over again.  I'd like to find
> solutions that change the dynamic in a more fundamental way, so that
> we buy a little more.  But I'm not going to complain too much; the
> performance gains we've gotten with these techniques are obviously
> quite substantial, even though they're not a total solution.

IIRC, pg_bench is *extremely* write-heavy. There's probably not that many systems that operate that way. I suspect that most OLTP systems read more than they write, and some probably have as much as a 10-1 ratio.

So... it might be interesting to run a more balanced pg_bench as well...
--
Jim C. Nasby, Database Architect                   jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net