Re: Review remove {join,from}_collapse_limit, add enable_join_ordering - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Review remove {join,from}_collapse_limit, add enable_join_ordering
Date
Msg-id 200907161752.53069.andres@anarazel.de
Whole thread Raw
In response to Re: Review remove {join,from}_collapse_limit, add enable_join_ordering  (Greg Stark <gsstark@mit.edu>)
Responses Re: Review remove {join,from}_collapse_limit, add enable_join_ordering
List pgsql-hackers
On Thursday 16 July 2009 17:27:39 Greg Stark wrote:
> On Thu, Jul 16, 2009 at 4:16 PM, Tom Lane<tgl@sss.pgh.pa.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.
Well, I could not find a plan where it errored out with the old limits. So one 
could argue its just not adapted.
Although I also could not find a single case where geqo was relevantly faster 
with the default settings even if it was used.
The default settings currently make it relatively hard to trigger geqo at all.


Andres


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Review remove {join,from}_collapse_limit, add enable_join_ordering
Next
From: Tom Lane
Date:
Subject: Re: Review remove {join,from}_collapse_limit, add enable_join_ordering