| From: | Dawid Kuroczko <qnex42(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-performance(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Planner doesn't look at LIMIT? |
| Date: | 2005-07-22 20:48:58 |
| Message-ID: | 758d5e7f05072213486919c8f4@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
On 7/22/05, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2005-07-22 21:46:40 | Re: Going to OSCON? We need your help! |
| Previous Message | Dave Page | 2005-07-22 20:42:54 | Re: Buildfarm failure - pl/tcl on snake |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Luke Lonergan | 2005-07-23 04:09:10 | Re: [PATCHES] COPY FROM performance improvements |
| Previous Message | Mark Wong | 2005-07-22 19:47:18 | Re: [PATCHES] COPY FROM performance improvements |