Hi!
Tom Lane writes:
> I'm not at all convinced that we should be putting effort into a
> homegrown, partial substitute for DTrace.
In my opinion providing DTrace as the only means of profiling would
except a number of users from the tuning benefits. DTrace seems to rely
on specific kernel options on Linux, which you might not be able to
influence if you run your business on leased virtual servers hosted
somewhere. DTrace is also not available for all platforms, most notably
Windows.
DTrace might be a great tool for the developers and should probably be
used. For the rest of the world I see a benefit in having something
like the proposed solution that could be enabled by the database
administrator on every server or maybe even be the default. I think it
would reduce the guesswork on why something might me slow and the work
on 'probable' causes and establish more of a 'tuning by numbers'
attitude.
Looking at the existing probes in HEAD it this seems to be your target
to provide high-level resource usage patterns to the user and I agree
that this is the right abstraction layer. With this proposal I see a
way of providing the resource usage in a (database) user-friendly way:
namely as tupels that the user can access in a familiar manner and
without using shell commands on a server that he might not even have
access to. I also see an easy way of keeping historic data by copying
the current state with a timestamp to a different table and then being
able to look at performance problems of last night when nobody was there
to notice it and fire up a profiler to watch it.
Just my 0.02€.
--
Stefan
