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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
