Tom Lane <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq