Re: New DTrace probes proposal

Поиск
Список
Период
Сортировка
От Robert Treat
Тема Re: New DTrace probes proposal
Дата
Msg-id 200806061701.06338.xzilla@users.sourceforge.net
обсуждение исходный текст
Ответ на Re: New DTrace probes proposal  (Robert Lor <Robert.Lor@Sun.COM>)
Ответы Re: New DTrace probes proposal
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Overhauling GUCS
Следующее
От: Ron Mayer
Дата:
Сообщение: Re: Overhauling GUCS