Re: New DTrace probes proposal

From: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Robert Lor <Robert(dot)Lor(at)sun(dot)com>
Subject: Re: New DTrace probes proposal
Date: 2008-06-06 16:18:12
Message-ID: 200806061218.12875.xzilla@users.sourceforge.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Saturday 17 May 2008 22:33:01 Robert Lor wrote:
> (Resending since it didn't work the first time. Not sure if attaching a
> tar file was the culprit.)
>
> I'd like to propose adding the following probes (some of which came from
> Simon) to 8.4.
>

+1

> I think these probe provide very useful data. Although some of the data
> can be collected now, the main advantages with probes, among others, are
> (1) they are always available and can be enabled only when needed
> especially in production (2) different combinations of probes can be
> used together to collect interesting data.
>
> They work on OS X Leopard & Solaris now, and hopefully on FreeBSD soon.
>

certainly by the time 8.4 ships, these should work with freebsd I'd think.
ideally we would need to confirm this by release time, certainly getting a
bsd buildfarm member to compile with them would be a start (and very unlikely
to cause issues)

> Preliminary patch attached along with sample DTrace scripts.
>

One thing I didnt understand after looking at this was...

> * Probes to measure query time
> query-parse-start (int, char *)

I would have guessed that the arguments might be pid and query string, but
looking at the probes, I see it defined as:

TRACE_POSTGRESQL_QUERY_PARSE_START(query_string);

which doesn't seem to match up... can you explain that piece?

Overall, I like the probes you have breaking down query
parsing/planning/executing, though I like ours for measuring autovacuum
pieces, so I think the end game should be to just merge the two patches
together (barring any place there is direct conflict)... do you see any
issues with that?

One other questions would be what to do with the dtrace scripts. I think
having a set of these available is a large boon for dtrace users, but do you
see that as something that needs to be distriubuted with the core? I'd lean
towards reviving the dtrace project on pgfoundry, but it might be worth
expanding the dynamic tracing chapter to include more examples and a pointer
to pgfoundry.

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jignesh K. Shah 2008-06-06 16:21:47 Proposal: New LWLockmode LW_OWNER
Previous Message Jonah H. Harris 2008-06-06 16:06:59 Re: orafce does NOT build with Sun Studio compiler