Re: Progress bar updates

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Neil Conway <neilc(at)samurai(dot)com> writes:
> > I'm not quite sure what you're suggesting; presumably you'd need to open
> > another client connection to send the "status report" message to a
> > backend (since a backend will not be polling its input socket during
> > query execution). That just seems like the wrong approach -- stashing a
> > backend's current status into shared memory sounds more promising, IMHO,
> > and won't require changes to the FE/BE protocol.
>
> Yeah, I was about to make the same comment. The new support for query
> status in shared memory should make it pretty cheap to update a progress
> indicator there, and then it'd be trivial to expose the indicator to
> other backends via pg_stat_activity.

I think that would be a fine feature too. But I don't think that reduces the
desire clients have to be able to request updates on the status of their own
queries.

> In practice, if a query is taking long enough for this feature to be
> interesting, making another connection and looking to see what's happening
> is not a problem, and it's likely to be the most practical way anyway for
> many clients.

It would be the most practical way for a DBA to monitor an application. But
it's not going to be convenient for clients like pgadmin or psql. Even a web
server may want to, for example, stream ajax code updating a progress bar
until it has results and then stream the ajax to display the results. Having
to get the backend pid before your query and then open a second database
connection to monitor your first connection would be extra footwork for
nothing.

--
greg