Subject: Re: Planner doesn't look at LIMIT?
From: Ian Westmacott <ianw@intellivid.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-performance@postgresql.org
In-Reply-To: <16040.1123714524@sss.pgh.pa.us>
References: <758d5e7f0507220210bfa4978@mail.gmail.com>
	<29473.1122043197@sss.pgh.pa.us> <6440.1122049220@sss.pgh.pa.us>
	<1123707833.17725.133.camel@spectre.intellivid.com>
	<16040.1123714524@sss.pgh.pa.us>
Content-Type: text/plain
Organization: Intellivid Corp.
Message-Id: <1123766797.21162.93.camel@spectre.intellivid.com>
Mime-Version: 1.0
Date: Thu, 11 Aug 2005 09:26:37 -0400
Content-Transfer-Encoding: 7bit

On Wed, 2005-08-10 at 18:55, Tom Lane wrote:
> Ian Westmacott <ianw@intellivid.com> 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