From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org, "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Dimitri Fontaine" <dim(at)hi-media(dot)com> |
Subject: | Re: *_collapse_limit, geqo_threshold |
Date: | 2009-07-11 16:43:19 |
Message-ID: | 200907111843.19488.andres@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On Saturday 11 July 2009 18:23:59 Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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
Using setstate() has a bit too many possible implications for my taste -
especially as there is no way to portably get/save the current random state.
(Running a known query to reset randoms seed or so)
> 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.
Yes.
> 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.
Okay.
It would be possible to implement random_r the same way if we are going to
write something for windows anyway - Is it possible that it might be usefull
somewhere else?
> 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...
That was my thinking as well.
Should geqo_seed be documented from start or not?
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-07-11 16:47:10 | Re: *_collapse_limit, geqo_threshold |
Previous Message | Tom Lane | 2009-07-11 16:23:59 | Re: *_collapse_limit, geqo_threshold |