Re: Progress indication prototype

From: Greg Stark <stark(at)mit(dot)edu>
To: Dave Page <dpage(at)pgadmin(dot)org>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers(at)postgresql(dot)org, Peter Eisentraut <peter_e(at)gmx(dot)net>, Alex Hunsaker <badalex(at)gmail(dot)com>
Subject: Re: Progress indication prototype
Date: 2010-08-18 12:45:49
Message-ID: AANLkTik+8x70hJfJDrdqm3sSm9Ti0a7W0eeCpgBzM9M7@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 17, 2010 at 11:29 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
> Which is ideal for monitoring your own connection - having the info in
> the pg_stat_activity is also valuable for monitoring and system
> administration. Both would be ideal :-)

Hm, I think I've come around to the idea that having the info in
pg_stat_activity would be very nice. I can just picture sitting in
pgadmin while a bunch of reports are running and seeing progress bars
for all of them...

But progress bars alone aren't really the big prize. I would really
love to see the explain plans for running queries. This would improve
the DBAs view of what's going on in the system immensely. Currently
you have to grab the query and try to set up a similar environment for
it to run explain on it. If analyze has run since or if the tables
have grown or shrank or if the query was run with some constants as
parameters it can be awkward. If some of the tables in the query were
temporary tables it can be impossible. You can never really be sure
you're looking at precisely the same plan than the other user's
session is running.

But stuffing the whole json or xml explain plan into pg_stat_activity
seems like it doesn't really fit the same model that the existing
infrastructure is designed around. It could be quite large and if we
want to support progress feedback it could change quite frequently.

We do stuff the whole query there (up to a limited size) so maybe I'm
all wet and stuffing the explain plan in there would be fine?

--
greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2010-08-18 12:49:51 Re: security label support, part.2
Previous Message Heikki Linnakangas 2010-08-18 12:20:15 pgsql: Coerce 'unknown' type parameters to the right type in the