On Sat, 2007-12-05 at 14:26 -0700, Joshua D. Drake wrote: > Either way, we are taking the hit, it is just a matter of where. IMO it > would be better to have the information in the database where it makes > sense, than pushing out to a log
If performance monitoring information is provided as a database object, what would the right interface be? IMHO the problem with cleanly presenting monitoring information within a normal database system is that this sort of data is fundamentally dynamic and continuous: to determine how the performance of the system changes over time, you need to repeatedly rescan the table/view/SRF and recompute your analysis essentially from scratch. Trying to get even simple information like "queries per second" from pg_stat_activity is an example of how this can be painful. <plug> BTW, if the system included the concept of a continuous data *stream* as a kind of database object, this problem would be much more tractable :) In fact, there is some code in a version of TelegraphCQ that exposes various information about the runtime state of the system as a set of system-defined data streams -- like any other stream, users could then use those streams in arbitrary queries. </plug> -Neil ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend