ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp> writes:
> Tom Lane <tgl@sss.pgh.pa.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

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Tom Lane wrote:

>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.
>
>
CVS head now has the following LWLock probes, and more can easily be
added. These probes can be enabled using the sample DTrace scripts at
http://pgfoundry.org/projects/dtrace/

lwlock-acquire
lwlock-release
lwlock-startwait
lwlock-endwait
lwlock-condacquire
lwlock-condacquire-fail

If anyone wants to have access to a Solaris machine to play with DTrace,
let me know.

Regards,
-Robert



---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Robert Lor <Robert.Lor@Sun.COM> wrote:

> CVS head now has the following LWLock probes, and more can easily be
> added. These probes can be enabled using the sample DTrace scripts at
> http://pgfoundry.org/projects/dtrace/
>
> lwlock-acquire
> lwlock-release
> lwlock-startwait
> lwlock-endwait
> lwlock-condacquire
> lwlock-condacquire-fail
>
> If anyone wants to have access to a Solaris machine to play with DTrace,
> let me know.

I assure you that DTrace is a powerful tool, but as for LWLock statistics,
can we gather them well with it? There is a "color coding" problem in the
persent dump-to-stderr and DTrace methods. I assume we want to gather the
statistics per resource (represented by LWLockKind in my patch), not per
LWLockId.

Even if we use DTrace, do we need some supports for coloring of lwlocks?

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


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp> writes:
> I assume we want to gather the statistics per resource (represented by
> LWLockKind in my patch), not per LWLockId.

Why? I haven't yet seen any problem where that looked useful.
The named LWLocks are certainly sui generis, and as for things like
per-buffer locks I haven't seen any need for aggregate statistics ---
I'd rather know about "hot spots" if there are any buffers that are
not like the rest.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org