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
Re: New DTrace probes proposal |
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: