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

From Robert Treat
Subject Re: New DTrace probes proposal
Date
Msg-id 200806061701.06338.xzilla@users.sourceforge.net
Whole thread Raw
In response to Re: New DTrace probes proposal  (Robert Lor <Robert.Lor@Sun.COM>)
Responses Re: New DTrace probes proposal  (Robert Lor <Robert.Lor@Sun.COM>)
List pgsql-hackers
On Friday 06 June 2008 14:32:27 Robert Lor wrote:
> 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.
>

We haven't ported our probes to 8.4 yet; the focus of our work has been to 
help people currently running postgres in production, and will probably 
remain with that focus untill closer to feature freeze. (Granted, if we get 
something into 8.4, we may just overhaul our to match that.)  While it would 
be nice to have a clean merge of the two, it's probably simple enough to just 
re-implement the differences into your patch (since yours already compiles on 
8.4).  As far as naming scheme, I'm not particularly wedded to either... is 
there a dtrace naming convention that could be followed? 

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


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Overhauling GUCS
Next
From: Ron Mayer
Date:
Subject: Re: Overhauling GUCS