Neil Conway wrote: > > 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.
We already have EXPLAIN ANALYZE. Perhaps the right way to do this is something that provides similar output. I could see something that looks like EXPLAIN for the parts that have not yet executed, something reasonable to show progress of the currently active part of the plan (current time, rows, loops), and EXPLAIN ANALYZE output for the parts which have been completed. I can see how this might lead to dynamically re-planning queries. Going backwards, perhaps there's something related to progress monitoring that could be taken from the TelegraphCQ work? Drew ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster