Re: Planner doesn't look at LIMIT?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ian Westmacott <ianw(at)intellivid(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Planner doesn't look at LIMIT?
Date: 2005-08-10 22:55:24
Message-ID: 16040.1123714524@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

Ian Westmacott <ianw(at)intellivid(dot)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.

If this wasn't chance, but was expected because there are many matching
rows and not only one, then there's a statistical problem.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Kings-Lynne 2005-08-11 02:33:12 SPARQL
Previous Message Tom Lane 2005-08-10 21:39:49 Re: Solving the OID-collision problem

Browse pgsql-performance by date

  From Date Subject
Next Message Dan Harris 2005-08-10 23:37:49 Speedier count(*)
Previous Message Ian Westmacott 2005-08-10 21:03:53 Re: Planner doesn't look at LIMIT?