Re: Proposed changes to DTrace probe implementation
От | Paul van den Bogaard |
---|---|
Тема | Re: Proposed changes to DTrace probe implementation |
Дата | |
Msg-id | EF0C21AC-E8E7-4938-A750-7AE42A81398C@sun.com обсуждение исходный текст |
Ответ на | Re: Proposed changes to DTrace probe implementation (Magnus Hagander <magnus@hagander.net>) |
Список | 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.vandenBogaard@sun.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
В списке pgsql-hackers по дате отправления:
Предыдущее
От: "Florian G. Pflug"Дата:
Сообщение: Re: An idea for parallelizing COPY within one backend