Hi Tom, On Saturday 11 July 2009 20:33:14 Tom Lane wrote: > Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
