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

From Kenneth Marshall
Subject Re: *_collapse_limit, geqo_threshold
Date
Msg-id 20090711172830.GA2043@it.is.rice.edu
Whole thread Raw
In response to Re: *_collapse_limit, geqo_threshold  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sat, Jul 11, 2009 at 12:23:59PM -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > 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?
> 
> random_r() isn't in the Single Unix Spec AFAICS, and I also don't find
> it on HPUX 10.20, so I'd vote against depending on it.  What I do see
> in SUS is initstate() and setstate() which could be used to control
> the random() function:
> http://www.opengroup.org/onlinepubs/007908799/xsh/initstate.html
> It would also work to leave random() for use by the core code and have
> GEQO depend on something from the drand48() family:
> http://www.opengroup.org/onlinepubs/007908799/xsh/drand48.html
> Probably drand48() is less random than random(), but for the limited
> purposes of GEQO I doubt we care very much.
> 
Ugh, tracking down problems caused a poor random number generator
is a difficult. Poor randomness often causes weird results from
algorithms that were designed around the assumption of a "random"
number.

> So far as I can find in a quick google search, neither of these families
> of functions exist on Windows :-(.  So I think maybe the best approach
> is the second one --- we could implement a port/ module that provides a
> version of whichever drand48 function we need.
> 
I think that having a port/module for a random number generator is a
good idea. There are a number of good, fast random number generators
to choose from.

Cheers,
Ken

> On reflection I think the best user API is probably a "geqo_seed" GUC in
> the range 0 to 1, and have GEQO always reset its seed to that value at
> start of a planning cycle.  This ensures plan stability, and if you need
> to experiment with alternative plans you can change to different seed
> values.  The "no reset" behavior doesn't seem to have much real-world
> usefulness, because even if you chance to get a good plan, you have no
> way to reproduce it...
> 
>             regards, tom lane
> 
> -- 
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
> 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: *_collapse_limit, geqo_threshold
Next
From: Andres Freund
Date:
Subject: Re: *_collapse_limit, geqo_threshold