On Mon, Oct 4, 2010 at 3:29 AM, Itagaki Takahiro
<itagaki.takahiro@gmail.com> wrote:
> * There are some overlaps between the feature and DTrace hooks.
> If we need such extension even though we have DTrace hooks,
> it might mean DTrace hooks are hard to use for average users
> and maybe also for postgres' hackers...
I've had it on my radar for a long time to make use of DTrace directly
in EXPLAIN output. The dtrace folk are really not interested in
programmatic access to the interfaces to the counters becasue they're
afraid it'll nail down internal interfaces too early. But I do think
there's lots of potential there.
> * Some kinds of statistical sampling could solve too much overhead
> in stop-watch based algorithm. Sampling is not always accurate,
> but it might have better balance between overhead and resolution.
>
Tom experimented with doing statistical sampling and found the results
were even worse than the overhead from stopwatch profiling. I think we
should be able to subtract the overhead from the measurements if it's
a problem. But actually in the case of getrusage stats I don't think
it's an issue. The main interesting bits in getrusage are inblock and
oublock which don't have any profiling overhead -- getrusage doesn't
do any i/o. if you're only concerned with the cpu run-time of an
in-memory query you don't really need to look at getrusage at all.
--
greg