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.
TODO updated:
* Have EXPLAIN ANALYZE issue NOTICE messages when the estimated and
actual row counts differ by a specified percentage
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
