On Wed, 2005-08-10 at 18:55, Tom Lane wrote:
> Ian Westmacott <[EMAIL PROTECTED]> writes:
> > In a nutshell, I have a LIMIT query where the planner
> > seems to favor a merge join over a nested loop.
>
> The planner is already estimating only one row out of the join, and so
> the LIMIT doesn't affect its cost estimates at all.
>
> It appears to me that the reason the nestloop plan is fast is just
> chance: a suitable matching row is found very early in the scan of
> tableB, so that the indexscan on it can stop after 29 rows, instead
> of having to go through all 55000 rows in the given range of bim.
> If it'd have had to go through, say, half of the rows to find a match,
> the sort/merge plan would show up a lot better.
Oh, I see. Thanks, that clears up some misconceptions I
had about the explain output.
> If this wasn't chance, but was expected because there are many matching
> rows and not only one, then there's a statistical problem.
Well, there are in fact almost 300 of them in this case.
So I guess what I need to do is give the planner more
information to correctly predict that.
Thanks,
--Ian
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
