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