Thanks Dave for the fast reaction!
I certainly understand it is not trivial: some way to poll the current
state of execution of a transaction would have to be implemented.
The idea of using EXPLAIN was simply that if (and only if) it would
simplify the implementation (because it gives the overall statistics
necessary to position the current execution state), the EXPLAIN overhead
is acceptable (it typically takes a second or two while transaction
execution often takes minutes if not hours).
A simpler thing to implement could be that EXPLAIN provides an estimate
of the total execution time.
Or even a cost indice: if I see that my computer executes a query with
cost indice X in one minute, I would know that it would take about 2
minutes to execute another query with cost indice 2X.
Have a nice evening,
Christophe
Dave Page a écrit :
> On Fri, Nov 27, 2009 at 3:27 PM, Christophe Dupriez
> <christophe.dupriez@destin.be> wrote:
>
>> Hi!
>>
>> I am using PgAdmin III and really like it a lot.
>> Some SQL queries are longer than other and I would like to suggest to have a
>> smarter progress bar than the milliseconds counter.
>>
>> I would suggest (if user enables it) that a progress bar giving the % of
>> completion of the evaluation steps.
>> * An "explain" would be run first to know the steps of the query execution.
>> * The execution would begin and the progress bar (% of completion) for each
>> step would be updated every seconds or so.
>>
>> This would keep me (and many other) quieter when executing big updates or
>> complex queries!
>>
>
> Unfortunately we have no way of knowing what node is currently being
> executed, nor how long it will take, or the progress through it. Greg
> Stark was working on a way to provide that information from PostgreSQL
> for exactly this purpose, but it's not entirely trivial.
>
> Running an EXPLAIN first is out of the question, as that could add a
> non-trivial amount of time to the overall query time.
>
>
