| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| 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-11 18:33:14 |
| Message-ID: | 22931.1247337194@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Shane Ambler | 2009-07-11 19:24:24 | Re: Odd historical fact about Bison |
| Previous Message | Andres Freund | 2009-07-11 18:27:27 | Re: *_collapse_limit, geqo_threshold |