Re: Query progress indication - an implementation
От | Robert Haas |
---|---|
Тема | Re: Query progress indication - an implementation |
Дата | |
Msg-id | 603c8f070906290715n2c91d477i2f95e9f8b8eb9fea@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Query progress indication - an implementation (Scara Maccai <m_lists@yahoo.it>) |
Ответы |
Re: Query progress indication - an implementation
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: