On 2014-10-07 10:45:24 -0400, Robert Haas wrote: > > It's not like it'd be significantly different today - in a read mostly > > workload that's bottlenecked on ProcArrayLock you'll not see many > > waits. There you'd have to count the total number of spinlocks cycles to > > measure anything interesting. > > Hmm, really? I've never had to do that to find bottlenecks.
How did you diagnose procarray contention in a readonly workload otherwise, without using perf? > >> Having said that, if there's no blocking or spindelay any more, to me > >> that doesn't mean we should look for some other measure of contention > >> instead. It just means that the whole area is a solved problem, we > >> don't need to measure contention any more because there isn't any, and > >> we can move on to other issues once we finish partying. But mildly > >> skeptical that the outcome will be as good as all that. > > > > It's not. Just because we're not waiting in a spinlock loop doesn't mean > > there can't be contention... It's just moved one level down, into the cpu. > > I guess that's true, but how much of the contention at that level is > really important to expose to DBAs? I think so. Right now it's hard to see for them whether the rate of transactions/the isolation mode is a significant problem or not. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
