On Mon, Jun 29, 2009 at 4:47 AM, Scara Maccai<m_lists@yahoo.it> wrote:
>> As to the content of the patch, I think that what you are doing is
>> comparing the actual number of "operations" with the expected number
>> of operations. If that's correct, I'm not sure it's really all that
>> useful, because it will only give you accurate
>> percentage-of-completion information when the estimates are
>> correct. But when the estimates are correct, you probably have a
>> pretty good idea how long the query will take to run anyway.
>
> That would be a first step. Having an idea of how much a query "progressed" is very important for long-running
queries.It's like
> copying files: even if you have a rough idea of how much time a copy will take, having an interface that tells you
thepercentage
> done is quite useful (IMHO).
I am all in favor of a query progress indicator; the trick is
constructing one that will actually be useful. It's easy to have
estimates that are off by a factor of two or three, though, so I think
you'd frequently have situations when the query completed when the
progress estimater was at 40% or 250%. Those kinds of progress
indicators tend to annoy users, and for good reason. File copying is
the sort of thing where it's pretty easy to estimate percentage of
completion by files and bytes; query execution is not.
So, I'm all in favor of what you're trying to conceptually; I just
don't like your proposed implementation.
...Robert
