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
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 |