Skip site navigation (1) Skip section navigation (2)

Re: Generic Monitoring Framework Proposal

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: (view raw, whole thread or download thread mbox)
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

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

In response to


pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2006-06-19 20:49:23
Subject: I was offline
Previous:From: Tom LaneDate: 2006-06-19 20:27:58
Subject: Re: Getting rid of extra gettimeofday() calls

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group