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

From Andres Freund
Subject Re: *_collapse_limit, geqo_threshold
Date
Msg-id 200907111719.19104.andres@anarazel.de
Whole thread Raw
In response to Re: *_collapse_limit, geqo_threshold  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: *_collapse_limit, geqo_threshold
Re: *_collapse_limit, geqo_threshold
List pgsql-hackers
On Wednesday 08 July 2009 23:46:02 Tom Lane wrote:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> > 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....
>
> If memory serves, we actually had exactly that at some point.  But I
> think the reason it got taken out was that it interfered with the
> behavior of the random() function for everything else.  We'd have to
> give GEQO its own private random number generator.
All of GEQOs usage of random() seems to be concentrated to geqo_random.h - so 
it would be a small change.
I will happily tackle that. If only to narrow down in which cases geqo fails 
to plan - a behaviour we have seen at times at a bit more crazy queries.

The only question I have is, whether random_r or similar is available on 
enough platforms... Has anybody an idea about this?
On most unixoid system one could just wrap erand48() if random_r is not 
available.
Windows?

Andres


pgsql-hackers by date:

Previous
From: Theo Schlossnagle
Date:
Subject: Re: concurrent index builds unneeded lock?
Next
From: Tom Lane
Date:
Subject: Re: concurrent index builds unneeded lock?