On Mon, Jan 9, 2012 at 7:24 PM, Jim Nasby <j...@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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers