Re: LWLOCK_STATS

On Mon, Jan 9, 2012 at 7:24 PM, Jim Nasby <jim(at)nasby(dot)net> wrote:
> 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...

Yeah, maybe. I've run read-only tests as well, and the tps rate is
~10x higher. So, certainly, you're going to do better if you have
more read-only transactions relative to write transactions. Not sure
what the exact shape of the curve is, but...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company