Re: *_collapse_limit, geqo_threshold

On Sunday 12 July 2009 16:44:59 Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On Saturday 11 July 2009 20:33:14 Tom Lane wrote:
> >> 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?
> I wouldn't count on that. GEQO is not recursive with respect to a
> particular query, but there's still the risk of the planner deciding
> to call out to some user-defined code while it does selectivity
> estimates. So the planner as a whole has to be re-entrant.

> Now you could probably argue that the impact of extra RNG resets on
> the overall behavior is small enough that it doesn't matter. But if
> you really want to promise consistent GEQO behavior then I think the
> RNG state has to be local to a particular planner instantiation.
I just did not see that it could call selectivity estimate functions. This
will mean adding a additional Paramer (PlannerInfo) to most of the geqo
functions, but I don't see a problem there.

Has anybody tried Geqo without ERX in recent time?

Andres