Re: Generic Monitoring Framework Proposal - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Generic Monitoring Framework Proposal
Date
Msg-id 21399.1150749626@sss.pgh.pa.us
Whole thread Raw
In response to Generic Monitoring Framework Proposal  (Robert Lor <Robert.Lor@Sun.COM>)
Responses Re: Generic Monitoring Framework Proposal  (Theo Schlossnagle <jesus@omniti.com>)
Re: Generic Monitoring Framework Proposal  (Robert Lor <Robert.Lor@Sun.COM>)
List pgsql-hackers
Robert Lor <Robert.Lor@Sun.COM> writes:
> The main goal for this Generic Monitoring Framework is to provide a
> common interface for adding instrumentation points or probes to
> Postgres so its behavior can be easily observed by developers and
> administrators even in production systems.

What is the overhead of a "probe" when you're not using it?  The answer
had better not include the phrase "kernel call", or this is unlikely to
pass muster...

> For DTrace, probes can be enabled using a D script. When the probes are not enabled, there is absolutely no
performancehit whatsoever. 
 

If you believe that, I have a bridge in Brooklyn you might be interested
in.

What are the criteria going to be for where to put probe calls?  If it
has to be hard-wired into the source code, I foresee a lot of contention
about which probes are worth their overhead, because we'll need
one-size-fits-all answers.

> arg1..arg5  = Any args to pass to the probe such as txn id, lock id, etc    
Where is the data type of a probe argument defined?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Getting rid of extra gettimeofday() calls
Next
From: Alvaro Herrera
Date:
Subject: I was offline