Richard Huxton wrote:
> Simon Riggs wrote:
> > Intermediate results are always better than none at all. I do understand
> > what a partial execution would look like - frequently it is the
> > preparatory stages that slow a query down - costly sorts, underestimated
> > hash joins etc. Other times it is loop underestimation, which can
> > usually be seen fairly quickly.
> Surely all you're interested in is where the actual plan differs from
> the expected plan? Could you not just have a mode that issues NOTICEs
> when expected/actual number of rows differ by more than a set amount?
> You'd probably want two NOTICEs - one when the threshold is exceeded,
> one when the node completes.
Right, we already have a TODO:
* Have EXPLAIN ANALYZE highlight poor optimizer estimates
I was thinking we could issue NOTICE when the estimates differed from
the actual by a specified percentage, and that NOTICE could be issued
while the query is still processing, assuming the stage completes before
the query does. This seems much easier than doing protocol changes.
* Have EXPLAIN ANALYZE issue NOTICE messages when the estimated and
actual row counts differ by a specified percentage
Bruce Momjian [EMAIL PROTECTED]
+ If your life is a hard drive, Christ can be your backup. +
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend