Re: *_collapse_limit, geqo_threshold

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: *_collapse_limit, geqo_threshold
Дата
Msg-id 200907111719.19104.andres@anarazel.de
обсуждение исходный текст
Ответ на Re: *_collapse_limit, geqo_threshold  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: *_collapse_limit, geqo_threshold  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: *_collapse_limit, geqo_threshold  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Wednesday 08 July 2009 23:46:02 Tom Lane wrote:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> > For a moment it seemed logical to suggest a session GUC for the seed,
> > so if you got a bad plan you could keep rolling the dice until you got
> > one you liked; but my right-brain kept sending shivers down my spine
> > to suggest just how uncomfortable it was with that idea....
>
> If memory serves, we actually had exactly that at some point.  But I
> think the reason it got taken out was that it interfered with the
> behavior of the random() function for everything else.  We'd have to
> give GEQO its own private random number generator.
All of GEQOs usage of random() seems to be concentrated to geqo_random.h - so 
it would be a small change.
I will happily tackle that. If only to narrow down in which cases geqo fails 
to plan - a behaviour we have seen at times at a bit more crazy queries.

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?

Andres


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Theo Schlossnagle
Дата:
Сообщение: Re: concurrent index builds unneeded lock?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: concurrent index builds unneeded lock?