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.
> 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.
