Re: Proposed changes to DTrace probe implementation

From: Paul van den Bogaard <Paul(dot)Vandenbogaard(at)Sun(dot)COM>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Robert Lor <Robert(dot)Lor(at)Sun(dot)COM>, Gregory Stark <stark(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposed changes to DTrace probe implementation
Date: 2008-02-27 15:58:57
Message-ID: EF0C21AC-E8E7-4938-A750-7AE42A81398C@sun.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

but putting these and other counters in context is what could be
missing. Correlating a given (set of) stats with others (possible
outside of the application domain) is one of the assets offered by
DTrace. Besides the generic transaction begin/start/end it could
also be helpful to see the number of parses,binds,executes per
transaction, user, connection etc.
And yes, I feel Tom is right in fearing that these things can be used
in "creative" ways. However is this not true for most benchmarks/
results when ones objective is to "show" how perfect/better/whatever
product/platform A behaves/is compared to B, C, etc...

One benefit for generalizing a subset of the DTrace probes is the
possibility of creating generic DTrace scripts that can be used for
many database installations. DTrace is great, programming DTrace
scripts is fun (my view, and sure I am biased as a Sun employee :-),
but it is not likely to be something a dba would like to master. The
availability of "generic" scripts does add value.

BTW I wonder if we could somehow combine DTrace as a contextual tool
with the counters provided through the stats interface. Any insight/
ideas?

--Paul.

On 27-feb-2008, at 10:28, Magnus Hagander wrote:

> On Tue, Feb 26, 2008 at 03:48:28PM -0600, Robert Lor wrote:
>> Gregory Stark wrote:
>>> I think both types of probes are useful to different people.
>>>
>> I think certain higher level probes can be really useful to DBAs.
>>> 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.
>>>
>> Great idea. I found this link for public RDBMS MIB
>> http://www.mnlab.cs.depaul.edu/cgi-bin/sbrowser.cgi?
>> HOST=&OID=RDBMS-MIB!rdbmsMIB
>>
>> The stats in rdbmsSrvInfoTable is quite useful, and it's one of the
>> tables that Oracle implements in their SNMP support.
>> http://download-east.oracle.com/docs/cd/B14099_19/manage.1012/
>> b16244/appdx_d_rdbms.htm
>
> Incidentally, most of that's already supported by the pg snmp
> provider,
> through the stats system.
>
> //Magnus
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq

------------------------------------------------------------------------
---------------------
Paul van den Bogaard
Paul(dot)vandenBogaard(at)sun(dot)com
ISV-E -- ISV Engineering, Opensource Engineering group

Sun Microsystems, Inc phone: +31
334 515 918
Saturnus 1
extentsion: x (70)15918
3824 ME Amersfoort mobile: +31
651 913 354
The Netherlands
fax: +31 334 515 001

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Dunstan 2008-02-27 16:33:18 Re: An idea for parallelizing COPY within one backend
Previous Message Florian G. Pflug 2008-02-27 15:56:14 Re: An idea for parallelizing COPY within one backend