On Wed, Jun 15, 2011 at 8:47 AM, Robert Haas <robertmh...@gmail.com> wrote:
> On Wed, Jun 15, 2011 at 3:34 AM, Greg Smith <g...@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
