Re: Proposed changes to DTrace probe implementation

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Robert Lor" <Robert(dot)Lor(at)Sun(dot)COM>, "pgsql-hackers list" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposed changes to DTrace probe implementation
Date: 2008-02-26 20:22:01
Message-ID: 87zltneady.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Possibly I have a different view of the uses of dtrace than you do, but
> most of the events I'd be interested in probing are probably pretty
> Postgres-specific.

I think both types of probes are useful to different people.

One of the really neat things about dtrace, imho, is that it lets you
correlate data from different levels of abstraction. You can find out how many
physical i/o's happen per i/o syscall. And how many i/o syscalls per database
transaction. And how many database transactions per application request. Etc.

Perhaps looking at the standard database SNMP MIB counters would give us a
place to start for upward facing events people want to trace for databases in
general.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Neil Conway 2008-02-26 20:26:11 Re: Two Coverity Scan volunteers needed
Previous Message Gregory Stark 2008-02-26 20:14:49 Re: pg_dump additional options for performance