Re: *_collapse_limit, geqo_threshold

Hi Tom,

On Saturday 11 July 2009 20:33:14 Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > I just realized doing it in a naive way (in geqo()) causes the state to
> > be reset multiple times during one query- at every invocation of
> > make_rel_from_joinlist.
> >
> > Does anybody see a problem with that?
>
> I think that's probably what we want.  Otherwise, you'd have a situation
> where two identical subproblems might get planned differently.
>
> This ties into something I was thinking about earlier: the planner is
> potentially recursive (eg, it might call a user-defined function that
> contains a plannable query), and it'd probably be a good idea if the
> behavior of GEQO wasn't sensitive to that.  So the RNG's state needs to
> be kept in PlannerInfo or some associated structure, not be global.
Hm. I looked a bit into this and I dont see a real problem with a global 
random state if that one gets reinitialized on every geqo() invocation. If I 
understood the code correctly - which is not sure at all -  while 
make_rel_from_joinlist is itself recursively the actual join search code is 
not recursive. Correct?
Thus it would be enough to reset the seed on every geqo() invocation...

Any counter arguments?

Andres