Re: Progress bar updates
От | Hannu Krosing |
---|---|
Тема | Re: Progress bar updates |
Дата | |
Msg-id | 1153301627.2905.1.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: Progress bar updates (Greg Stark <gsstark@mit.edu>) |
Список | pgsql-hackers |
Ühel kenal päeval, K, 2006-07-19 kell 05:18, kirjutas Greg Stark: > Tom Lane <tgl@sss.pgh.pa.us> writes: > > > Neil Conway <neilc@samurai.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
В списке pgsql-hackers по дате отправления: