On 7/22/05, Tom Lane <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org