Re: *_collapse_limit, geqo_threshold
От | Andres Freund |
---|---|
Тема | Re: *_collapse_limit, geqo_threshold |
Дата | |
Msg-id | 200907111843.19488.andres@anarazel.de обсуждение исходный текст |
Ответ на | Re: *_collapse_limit, geqo_threshold (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: *_collapse_limit, geqo_threshold
|
Список | pgsql-hackers |
Hi, On Saturday 11 July 2009 18:23:59 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 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
В списке pgsql-hackers по дате отправления: