Re: Progress bar updates

From: Hannu Krosing <hannu(at)skype(dot)net>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Neil Conway <neilc(at)samurai(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Progress bar updates
Date: 2006-07-19 09:33:47
Message-ID: 1153301627.2905.1.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ühel kenal päeval, K, 2006-07-19 kell 05:18, kirjutas Greg Stark:
> 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.

another \x command could be added to psql to do just that

> > 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.

You would have to do some extra work anyway. opening another connection
is not such a big deal.

--
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me: callto:hkrosing
Get Skype for free: http://www.skype.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Page 2006-07-19 09:35:44 Re: Progress bar updates
Previous Message Greg Stark 2006-07-19 09:18:55 Re: Progress bar updates