Re: [GENERAL] join_collapse_limit = 14

På lørdag 07. januar 2017 kl. 18:25:42, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>: Andreas Joseph Krogh writes: > På lørdag 07. januar 2017 kl. 17:48:49, skrev Tom Lane >: >  If you've got just one problem query, it might be worth your time to take >  note of the op

Re: [GENERAL] join_collapse_limit = 14

Andreas Joseph Krogh writes: > På lørdag 07. januar 2017 kl. 17:48:49, skrev Tom Lane >: > 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 q

Re: [GENERAL] join_collapse_limit = 14

På lørdag 07. januar 2017 kl. 17:48:49, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>: Andreas Joseph Krogh writes: > I wonder; In general, is there any downside of having join_collapse_limit = 14 > on modern hardware (32 cores, 64GB RAM), and geqo_threshold=16 ? > I'm aware of it increasing plan

Re: [GENERAL] join_collapse_limit = 14

Andreas Joseph Krogh writes: > I wonder; In general, is there any downside of having join_collapse_limit = > 14 > on modern hardware (32 cores, 64GB RAM), and geqo_threshold=16 ? > I'm aware of it increasing planning-time, but is this really an issue in > practice? It can be. The number of po

[GENERAL] join_collapse_limit = 14

Hi all.   I have a query which takes forever and the only way I've been able to make it perform reasonably well is increasing join_collapse_limit to 14 (12 still produced lots of nest-loops). This way lots of nest-loops (which I think caused the slowness) was made into hash-joins and performance