Re: LWLock statistics collector

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: LWLock statistics collector
Date: 2006-08-04 15:53:52
Message-ID: 29344.1154706832@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> writes:
> 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.

Then you'd need an initdb to go between having stats and not, which
carries its own downsides. If I thought there were a wide market for
this then I'd say sure, let's just have it there ... but I don't.

I think the actual wave of the future for analyzing behavior at the
LWLock level is going to be DTrace. It seems way more flexible than
an aggregate-statistics view can be.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2006-08-04 16:01:42 Re: 8.2 features status
Previous Message Tom Lane 2006-08-04 15:46:52 Re: standard interfaces for replication providers

Browse pgsql-patches by date

  From Date Subject
Next Message Robert Lor 2006-08-04 16:41:52 Re: LWLock statistics collector
Previous Message Simon Riggs 2006-08-04 11:12:36 Re: [PATCHES] Forcing current WAL file to be archived