Re: procpid?

On Wed, Jun 15, 2011 at 8:47 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Wed, Jun 15, 2011 at 3:34 AM, Greg Smith <greg(at)2ndquadrant(dot)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