On Tue, Oct 7, 2014 at 10:36 AM, Andres Freund <and...@2ndquadrant.com> wrote: >> That gets painful in a hurry. We just got rid of something like that >> with your patch to get rid of all the backend-local buffer pin arrays; >> I'm not keen to add another such thing right back. > > I think it might be ok if we'd exclude buffer locks and made it depend > on a GUC.
Maybe. I'm skeptical about whether what you'll get at that point is really useful. > 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. >> 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. -- 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
