It would be useful to track timing for different operations and aggregate these values at request / transaction / connection / database levels as other runtime statsitics is maintained. In particular, I was thinking about total time spent, CPU time (maybe separated for user / kernel) and various waiting time - database I/O waits, lock manager waits, cache latch waits, etc. This opens wide possibilities for tracking down the performance issues. Note that I don't suggest tracking time for particular sub-operations (retrievals, sorts, joins, etc), so it's not about profiling the algorithms. It's more about finding bottlenecks in I/O or contention.
As time tracking is likely to be a costly operation, it should be disabled by default and enabled explicitly by the DBA, probably for either particular connections or globally for a database.
Submitted by: @dyemanov
Votes: 5
It would be useful to track timing for different operations and aggregate these values at request / transaction / connection / database levels as other runtime statsitics is maintained. In particular, I was thinking about total time spent, CPU time (maybe separated for user / kernel) and various waiting time - database I/O waits, lock manager waits, cache latch waits, etc. This opens wide possibilities for tracking down the performance issues. Note that I don't suggest tracking time for particular sub-operations (retrievals, sorts, joins, etc), so it's not about profiling the algorithms. It's more about finding bottlenecks in I/O or contention.
As time tracking is likely to be a costly operation, it should be disabled by default and enabled explicitly by the DBA, probably for either particular connections or globally for a database.