On Sunday 12 July 2009 16:44:59 Tom Lane wrote: > Andres Freund <and...@anarazel.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
