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

From Tom Lane
Subject Re: *_collapse_limit, geqo_threshold
Date
Msg-id 19773.1247329439@sss.pgh.pa.us
Whole thread Raw
In response to Re: *_collapse_limit, geqo_threshold  (Andres Freund <andres@anarazel.de>)
Responses Re: *_collapse_limit, geqo_threshold
Re: *_collapse_limit, geqo_threshold
Re: *_collapse_limit, geqo_threshold
List pgsql-hackers
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.

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.

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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: concurrent index builds unneeded lock?
Next
From: Andres Freund
Date:
Subject: Re: *_collapse_limit, geqo_threshold