On Wed, Jun 15, 2011 at 3:34 AM, Greg Smith <greg@2ndquadrant.com> wrote: > The whole thing is enormously frustrating, and it's an advocacy problem--it > contributes to people just starting to become serious about using PostgreSQL > lowering their opinion of its suitability for their business. If this is > what's included for activity monitoring, and it's this terrible, it suggest > people must not have very high requirements for that.
Well, if we're going to start complaining about the lack of proper activity monitoring, the problems that you're talking about are just the tip of the iceberg. Don't even get me started.
> Putting on my stability hat instead of my "make it right" one, maybe this > really makes sense to expose as a view with a whole new name. Make this new > one pg_activity (there's no stats here anyway), keep the old one around as > pg_stat_activity for a few releases until everyone has converted to the new > one.
Now, that's a suggestion I could very possibly get behind. Though the fact that it would leave us with pg_activity / pg_stat_replication seems less than ideal. Maybe pg_activity isn't the best name either... bikeshedding time!
Why not expose this new information as functions instead of a new view, like we do for pg_is_in_replication(). People can use whatever alias they want in the queries they write.
SELECT get_current_query(pid), is_idle(pid), is_idle_in_transaction(pid), transaction_start_time(pid), .... FROM (select procpid as pid FROM pg_stat_activity);
Then pg_activity (or whatever we name it later) would also be a view on top of these functions.
--
Gurjeet Singh EnterpriseDB Corporation The Enterprise PostgreSQL Company
