A key issue in the road towards a high performance application is to understand where resources are being spent. This information can be obtained using different tools and at different levels of abstraction. A coarse-grained insight for a particular application can be obtained using injection of the necessary performance capturing statements in the MAL instruction sequence. Fine-grained, platform specific information can be obtained using existing profilers, like valgrind (http://www.valgrind.org), or hardware performance counters.
MonetDB comes with a set of profiling tools, including stethoscope, tomograph and tachograph, geared at understanding the internal working, scheduling, and potential resource bottlenecks raised by running queries. They are all based on a profiler event stream started by the system upon request. Together, they facilitate both online and off-line inspection of database queries.
The execution profiler is supported by hooks in the MAL interpreter. The default strategy is to ship an event record immediately over a stream to a separate performance monitor, formatted as a tuple.
Profiling a system is a potential security leak. Therefore, at any time there can only be one user accessing the profile information and he will only see events that originate under the same user-id. The profile information of concurrent queries ran by different users should be taken with a grain of salt. Currently, the single profile stream can be grabbed by any user.