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
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 |
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 |