On Mon, Jan 9, 2012 at 7:24 PM, Jim Nasby <jim@nasby.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
thatmost 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
