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
18 messages in org.postgresql.pgsql-hackersRe: Progress bar updates
