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
mostOLTP 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
