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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
