Re: *_collapse_limit, geqo_threshold

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "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 15:19:18
Message-ID: 200907111719.19104.andres@anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wednesday 08 July 2009 23:46:02 Tom Lane wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-07-11 16:02:14 Re: concurrent index builds unneeded lock?
Previous Message andrzej barszcz 2009-07-11 14:37:03 xml in ruleutils