On Tue, Oct 7, 2014 at 4:45 PM, Robert Haas <robertmh...@gmail.com> 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.
Not sure. Long waiting time represents the same thing better or at least well enough. I think only acquisitions count is important. >>> 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? We can put anything that is of > developer interest only int LWLOCK_STATS. For DBA all this means we are waiting for a lock. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company -- Ilya Kosmodemiansky, PostgreSQL-Consulting.com tel. +14084142500 cell. +4915144336040 i...@postgresql-consulting.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
