Re: New DTrace probes proposal - Mailing list pgsql-hackers

From Robert Lor
Subject Re: New DTrace probes proposal
Date
Msg-id 484982BB.3000907@sun.com
Whole thread Raw
In response to Re: New DTrace probes proposal  (Robert Treat <xzilla@users.sourceforge.net>)
Responses Re: New DTrace probes proposal  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: New DTrace probes proposal  (Robert Treat <xzilla@users.sourceforge.net>)
List pgsql-hackers
Robert Treat wrote:
>
> 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)
>   
As soon as the DTrace port is working on FreeBSD, I will confirm that 
the probes are working properly, and it's definitely a good idea to get 
a buildfarm machine building with --enable-dtrace.
> 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? 
>   
Having the pid passed as an argument was my original intention, but it's 
actually redundant since the pid is readily available from the script, 
so I will fix the other probes with pid as args.
>
> 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? 
>   
Yes, to avoid confusion, the probes should be merged and resubmitted as 
one patch. Have yours been ported to 8.4 yet? We also need to make sure 
the names and arg types are consistent, probably should work on this 
offline.
> 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 don't see the need to include the scripts with core now, maybe some 
point in the future if it makes sense.
>  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.  
>   
Agreed on both. I will add the new scripts to the dtrace project on 
PgFoundry and add more info to the doc. I think you guys have some 
interesting scripts as well that folks will find useful.

-Robert



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Proposal: New LWLockmode LW_OWNER
Next
From: Andreas Pflug
Date:
Subject: Re: Overhauling GUCS