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
