Re: LWLock statistics collector

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> This seems fairly invasive, as well as confused about whether it's an
> #ifdef'able thing or not. You can't have system views and pg_proc
> entries conditional on a compile-time #ifdef, so in a default build
> we would have a lot of nonfunctional cruft exposed to users.

Is it acceptable if pg_stat_lwlocks view and other functions are not
installed and invisible when LWLOCK_STAT is not defined? We don't have
such a feature now, but we can.

> Do we really need this compared to the simplistic dump-to-stderr
> counting support that's in there now? That stuff doesn't leave any
> cruft behind when not enabled, and it has at least one significant
> advantage over your proposal, which is that it's possible to get
> per-process statistics when needed.

There is one advantage in my proposal. We can watch the time-varying
activities of LWLocks easily.
Is per-process statistics actually needed? If we use connection
pooling, we lose the advantage. I think connection pooling is commonly
used in such a high-load case where we encounter LWLock contentions.

> If I thought that average users would have a need for LWLock statistics,
> I'd be more sympathetic to expending effort on a nice frontend for
> viewing the statistics, but this is and always will be just a concern
> for hardcore hackers ...

I assume the ones who analyze the output of the patch are hardcore hacker,
but the ones who actually use it and collect information are average users.
The dump-to-stderr method is hard to use because it will increase syslogs
and requires re-parsing efforts.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center