Re: Planner doesn't look at LIMIT?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Planner doesn't look at LIMIT?
Дата
Msg-id 16040.1123714524@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Planner doesn't look at LIMIT?  (Ian Westmacott <ianw@intellivid.com>)
Ответы Re: Planner doesn't look at LIMIT?  (Ian Westmacott <ianw@intellivid.com>)
Список pgsql-performance
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.

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

В списке pgsql-performance по дате отправления:

Предыдущее
От: Ian Westmacott
Дата:
Сообщение: Re: Planner doesn't look at LIMIT?
Следующее
От: Dan Harris
Дата:
Сообщение: Speedier count(*)