Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept)

On Tue, Oct 7, 2014 at 4:45 PM, Robert Haas <robertmhaas(at)gmail(dot)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
ik(at)postgresql-consulting(dot)com