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

From Andres Freund
Subject Re: *_collapse_limit, geqo_threshold
Date
Msg-id 200907140234.04195.andres@anarazel.de
Whole thread Raw
In response to Re: *_collapse_limit, geqo_threshold  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Saturday 11 July 2009 17:19:18 Andres Freund wrote:
> 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.
Sorry, had to stall the issue for a bit of time, here is a preliminary patch.

- added a "void *join_search_private"  to hold the random number generator 
which would also be usable by other join
- PlannerInfo *root is now passed to all non-static geqo related functions. It 
seems cleaner to do this generally than on a function-by-function basis
- replaced the sparsely used GeqoPrivateData by GeqoEvalData which is passed 
via join_search_private
- if geqo_seed = 0  a global/per-backend state is used

Whats missing:
- Windows prng support
- Perhaps: Configure check for erand48
- Documentation for geqo_seed

I did not find any windows api for a random number generator with 
visible/changable state, so I think there is not much alternative to pulling 
in random_r or similar from *bsd if this seems worth pursuing

Mostly sensible?

Andres


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [GENERAL] large object does not exist after pg_migrator
Next
From: Bruce Momjian
Date:
Subject: Re: [GENERAL] large object does not exist after pg_migrator