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 по дате отправления: