On Mon, Oct 4, 2010 at 3:29 AM, Itagaki Takahiro <itagaki.takah...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
