From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Subject: | Re: Review remove {join,from}_collapse_limit, add enable_join_ordering |
Date: | 2009-07-16 15:27:39 |
Message-ID: | 407d949e0907160827j45cc0a8ct98a49f56ddcd3768@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jul 16, 2009 at 4:16 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> However, I do observe that this seems a sufficient counterexample
> against the theory that we can just remove the collapse limits and let
> GEQO save us on very complex queries. On my machine, the example query
> takes about 22 seconds to plan using CVS HEAD w/ all default settings.
> If I set both collapse_limit variables to very high values (I used 999),
> it takes ... um ... not sure; I gave up waiting after half an hour.
What's the point of GEQO if it doesn't guarantee to produce the
optimal plana and *also* doesn't guarantee to produce some plan, any
plan, within some reasonable amount of time? Either we need to fix
that or else I don't see what it's buying us over our regular planner
which also might not produce a plan within a reasonable amount of time
but at least if it does it'll be the right plan.
From | Date | Subject | |
---|---|---|---|
Next Message | Zdenek Kotala | 2009-07-16 15:30:30 | Re: boolean in C |
Previous Message | Tom Lane | 2009-07-16 15:16:31 | Re: Review remove {join, from}_collapse_limit, add enable_join_ordering |