Re: Query progress indication - an implementation

On Mon, Jun 29, 2009 at 8:15 PM, Ron Mayer<rm_pg(at)cheapcomplexdevices(dot)com> wrote:
> Greg Stark wrote:
>>
>> Right, that was why my proposed interface was to dump out the explain
>> plan with the number of loops, row counts seen so far, and approximate
>> percentage progress.
>>
>> My thinking was that a human could interpret that to understand where
>> the bottleneck is if, say you're still on the first row for the top
>> few nodes but all the nodes below a certain sort have run to
>> completion that the query is busy running the sort...
>
> +1.  Especially if I run it a few times and I can see which counters
> are still moving.

+1 from me, too, as I said upthread.

>> Basically I disagree that imperfect progress reports annoy users. I
>> think we can do better than reporting 250% done or having a percentage
>> that goes backward though. It would be quite tolerable (though perhaps
>> for no logical reason) to have a progress indicator which slows done
>> as it gets closer to 100% and never seems to make it to 100%.
>
> -1.    A counter that slowly goes from 99% to 99.5% done is
> much worse than a counter that takes the same much time
> going from "1000% of estimated rows done" to "2000% of
> estimated rows done".
>
> The former just tells me that it lies about how much is done.
> The latter tells me that it's processing each row quickly but
> that the estimate was way off.

I think both of those options are a little wacky. Maybe 800% **of
estimated rows done** is not so bad, since the tag line provides some
context, but what does it mean exactly? Rows for the toplevel plan
node? That doesn't seem like it would always be too useful. I keep
coming back to thinking you need to see the whole tree.

...Robert