Re: Progress bar updates
От | Neil Conway |
---|---|
Тема | Re: Progress bar updates |
Дата | |
Msg-id | 1153273963.5447.14.camel@localhost обсуждение исходный текст |
Ответ на | Progress bar updates (Gregory Stark <gsstark@mit.edu>) |
Ответы |
Re: Progress bar updates
Re: Progress bar updates |
Список | pgsql-hackers |
On Tue, 2006-07-18 at 14:35 -0400, Gregory Stark wrote: > My first thought would be a message like CancelQuery which would cause the > backend to peek into a static data structure and return a message that the > client could parse and display something intelligent. 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. > I would suggest starting with utility functions like index builds or COPY > which would have to be specially handled anyways. Handling all optimizable > queries in a single generic implementation seems like something to tackle only > once the basic infrastructure is there and working for simple cases. > > Of course the estimates would be not much better than guesses. Estimating query progress for DDL should be reasonably doable, but I think it would require some hard thought to get even somewhat accurate estimates for SELECT queries -- and I'm not sure there's much point doing this if we don't at least have an idea how we might implement reasonably accurate progress reporting for every kind of query. This paper is worth a read: Gang Luo, Jeffrey F.Naughton, Curt Ellmann and Michael Watzke: Toward a Progress Indicator for Database Queries. SIGMOD Conference 2004: 791-802. Interestingly, they apparently implemented a prototype using PostgreSQL. -Neil
В списке pgsql-hackers по дате отправления: