Re: *_collapse_limit, geqo_threshold - Mailing list pgsql-hackers

From Tom Lane
Subject Re: *_collapse_limit, geqo_threshold
Date
Msg-id 22931.1247337194@sss.pgh.pa.us
Whole thread Raw
In response to Re: *_collapse_limit, geqo_threshold  (Andres Freund <andres@anarazel.de>)
Responses Re: *_collapse_limit, geqo_threshold  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: *_collapse_limit, geqo_threshold
Next
From: Shane Ambler
Date:
Subject: Re: Odd historical fact about Bison