From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Lor <Robert(dot)Lor(at)Sun(dot)COM> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Generic Monitoring Framework Proposal |
Date: | 2006-06-19 20:40:26 |
Message-ID: | 21399.1150749626@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Lor <Robert(dot)Lor(at)Sun(dot)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 performance hit 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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2006-06-19 20:49:23 | I was offline |
Previous Message | Tom Lane | 2006-06-19 20:27:58 | Re: Getting rid of extra gettimeofday() calls |