Re: *_collapse_limit, geqo_threshold - Mailing list pgsql-hackers

From Kenneth Marshall
Subject Re: *_collapse_limit, geqo_threshold
Date
Msg-id 20090708211826.GK22588@it.is.rice.edu
Whole thread Raw
In response to Re: *_collapse_limit, geqo_threshold  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
On Wed, Jul 08, 2009 at 04:13:11PM -0500, Kevin Grittner wrote:
> Tom Lane <tgl@sss.pgh.pa.us> wrote: 
>  
> > It occurs to me that one way to make GEQO less scary would be to
> > take out the nondeterminism by resetting its random number generator
> > for each query.  You might get a good plan or an awful one, but at
> > least it'd be the same one each time.  DBAs like predictability.
>  
> +1  The biggest reason that I've tended to avoid geqo is that I would
> never know when it might do something really stupid with a query one
> time out of some large number, leading to mysterious complaints which
> could eat a lot of time.
>  
> For a moment it seemed logical to suggest a session GUC for the seed,
> so if you got a bad plan you could keep rolling the dice until you got
> one you liked; but my right-brain kept sending shivers down my spine
> to suggest just how uncomfortable it was with that idea....
>  
> -Kevin
> 

+1  I like the idea of a session GUC for the random number seed. If
we can come up with a way to prune the search space more aggressively,
GECO (or GECO2) will be much less prone to generating a bad plan.
I also think that a session variable would make it easier to test
GECO* by removing the nondeteminism.

Ken


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: *_collapse_limit, geqo_threshold
Next
From: Tom Lane
Date:
Subject: Re: *_collapse_limit, geqo_threshold