Re: Generic Monitoring Framework Proposal
От | Tom Lane |
---|---|
Тема | Re: Generic Monitoring Framework Proposal |
Дата | |
Msg-id | 21399.1150749626@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Generic Monitoring Framework Proposal (Robert Lor <Robert.Lor@Sun.COM>) |
Ответы |
Re: Generic Monitoring Framework Proposal
Re: Generic Monitoring Framework Proposal |
Список | 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 по дате отправления: