Greg Stark wrote:
It seems pointless to me to expose things like lwlock_acuire that map 1-1 to C
function calls like LWLockAcquire. They're useless except to people who
understand what's going on and if people know the low level implementation
details of Postgres they can already trace those cal
Simon Riggs wrote:
This needs to work on Linux and Windows, minimum, also.
The proposed solution will work on Linux & Windows if they similar
facility that the macros can map to. Otherwise, the macros stay as
no-ops and will not affect those platforms at all.
It's obviously impossible to
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > What would be useful is instrumenting high level calls that can't be traced
> > without application guidance. For example, inserting a dtrace probe for each
> > SQL and each plan node. That way someone could get the
Greg Stark <[EMAIL PROTECTED]> writes:
> What would be useful is instrumenting high level calls that can't be traced
> without application guidance. For example, inserting a dtrace probe for each
> SQL and each plan node. That way someone could get the same info as EXPLAIN
> ANALYZE from a producti
Robert Lor <[EMAIL PROTECTED]> writes:
> Yes, I'm proposing user-space probes (aka User Statically-Defined Tracing -
> USDT). USDT provides a high-level abstraction so the application can expose
> well defined probes without the user having to know the detailed
> implementation. For example, ins
On Mon, Jun 19, 2006 at 05:14:15PM -0400, Chris Browne wrote:
> [EMAIL PROTECTED] (Robert Lor) writes:
> > For DTrace, probes can be enabled using a D script. When the probes
> > are not enabled, there is absolutely no performance hit whatsoever.
>
> That seems inconceivable.
>
> In order to have
On Mon, 2006-06-19 at 19:36 -0400, Theo Schlossnagle wrote:
> The idea of having intelligently placed dtrace probes in Postrgres
> would allow us
...
> to troubleshoot[ing] obtuse production
> problems. That, to me, is exciting stuff.
[paraphrased by SR]
I very much agree with the requireme
On Jun 19, 2006, at 7:39 PM, Mark Kirkwood wrote:
We will need to benchmark on FreeBSD to see if those comments about
overhead stand up to scrutiny there too.
I've followed the development of DTrace on FreeBSD and the design
approach is mostly identical to the Solaris one. This would mean
Jim C. Nasby wrote:
On Mon, Jun 19, 2006 at 05:20:31PM -0400, Theo Schlossnagle wrote:
Heh. Syscall probes and FBT probes in Dtrace have zero overhead.
User-space probes do have overhead, but it is only a few instructions
(two I think). Besically, the probe points are replaced by illegal
On Jun 19, 2006, at 6:41 PM, Robert Lor wrote:
Theo Schlossnagle wrote:
Heh. Syscall probes and FBT probes in Dtrace have zero
overhead. User-space probes do have overhead, but it is only a
few instructions (two I think). Besically, the probe points are
replaced by illegal instru
Theo Schlossnagle wrote:
Heh. Syscall probes and FBT probes in Dtrace have zero overhead.
User-space probes do have overhead, but it is only a few instructions
(two I think). Besically, the probe points are replaced by illegal
instructions and the kernel infrastructure for Dtrace will
[EMAIL PROTECTED] (Robert Lor) writes:
> For DTrace, probes can be enabled using a D script. When the probes
> are not enabled, there is absolutely no performance hit whatsoever.
That seems inconceivable.
In order to have a way of deciding whether or not the probes are
enabled, there has *got* to
On Mon, Jun 19, 2006 at 05:20:31PM -0400, Theo Schlossnagle wrote:
> Heh. Syscall probes and FBT probes in Dtrace have zero overhead.
> User-space probes do have overhead, but it is only a few instructions
> (two I think). Besically, the probe points are replaced by illegal
> instructions
Tom Lane wrote:
Robert Lor <[EMAIL PROTECTED]> 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 syste
On Jun 19, 2006, at 4:40 PM, Tom Lane wrote:
Robert Lor <[EMAIL PROTECTED]> 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
administrato
Robert Lor <[EMAIL PROTECTED]> 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 th
Motivation:
--
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. This framework will allow Post
17 matches
Mail list logo
