Re: *_collapse_limit, geqo_threshold

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
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:23:59
Message-ID: 19773.1247329439@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2009-07-11 16:43:19 Re: *_collapse_limit, geqo_threshold
Previous Message Tom Lane 2009-07-11 16:02:14 Re: concurrent index builds unneeded lock?