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 j...@nasby.net 512.569.9461 (cell) http://jim.nasby.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers