From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org, "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Dimitri Fontaine" <dim(at)hi-media(dot)com> |
Subject: | Re: *_collapse_limit, geqo_threshold |
Date: | 2009-07-12 12:57:53 |
Message-ID: | 200907121457.54132.andres@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Tom,
On Saturday 11 July 2009 20:33:14 Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2009-07-12 13:14:49 | Re: WIP: Deferrable unique constraints |
Previous Message | Sam Mason | 2009-07-12 12:57:42 | Re: New types for transparent encryption |