På lørdag 07. januar 2017 kl. 18:25:42, skrev Tom Lane <t...@sss.pgh.pa.us <mailto:t...@sss.pgh.pa.us>>: Andreas Joseph Krogh <andr...@visena.com> writes: > På lørdag 07. januar 2017 kl. 17:48:49, skrev Tom Lane <t...@sss.pgh.pa.us > <mailto:t...@sss.pgh.pa.us>>: > If you've got just one problem query, it might be worth your time to take > note of the optimal join order (as seen in EXPLAIN when a good plan is > chosen) and rearrange the query so that the syntactic join order matches > that. Then you should get the same plan even when join_collapse_limit is > small.
> Will geqo kick if if join_collapse_limit =4 and there are many more joins or > will the planner just stop trying to rearrange JOINs after this limit? geqo_threshold applies to the size of the join subproblems that exist after flattening is done, or not done, according to join_collapse_limit and from_collapse_limit: if a subproblem is >= geqo_threshold relations then it's planned via geqo, else the normal search. So if geqo_threshold is more than join_collapse_limit then it's impossible for a JOIN nest to result in use of the geqo code. > In any case; I assume you're suggesting doing something like "SET LOCAL > join_collapse_limit=<some-value>" in the same transaction so this doesn't have > to be a system-wide setting? Right, there's no reason not to set it locally in your session for experimental purposes. I'd just be nervous about turning it up globally for production without having checked all your queries ... regards, tom lane OK, thanks. -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>
