Re: [PERFORM] Planner doesn't look at LIMIT?
| От | Dawid Kuroczko |
|---|---|
| Тема | Re: [PERFORM] Planner doesn't look at LIMIT? |
| Дата | |
| Msg-id | 758d5e7f05072213486919c8f4@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [PERFORM] Planner doesn't look at LIMIT? (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
On 7/22/05, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > This is quite strange. The nestloop plan definitely should be preferred
> > in the context of the LIMIT, considering that it has far lower estimated
> > cost. And it is preferred in simple tests for me.
>
> After a suitable period of contemplating my navel, I figured out
> what is going on here: the total costs involved are large enough that
> the still-fairly-high startup cost of the hash is disregarded by
> compare_fuzzy_path_costs(), and so the nestloop is discarded as not
> having any significant potential advantage in startup time.
>
> I think that this refutes the original scheme of using the same fuzz
> factor for both startup and total cost comparisons, and therefore
> propose the attached patch.
>
> Comments?
Works great!!!
With LIMIT below 4 000 000 rows (its 47-milion row table) it prefers
nested loops, then it starts to introduce merge joins.
Regards,
Dawid
В списке pgsql-hackers по дате отправления: