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
