Re: New DTrace probes proposal

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