| From: | Marco Di Cesare <Marco(dot)DiCesare(at)pointclickcare(dot)com> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Merlin Moncure <mmoncure(at)gmail(dot)com> |
| Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Query with large number of joins |
| Date: | 2014-10-21 20:02:53 |
| Message-ID: | b0a3ad6dc2194646a776b3a1bcdb3ed3@CO2PR0701MB759.namprd07.prod.outlook.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On 10/21/2014 12:31 PM, Andrew Dunstan wrote:
> Please don't top-post on the PostgreSQL lists. See <http://idallen.com/topposting.html>
Oops, sorry.
>Have you tried a) either turning off geqo or setting geqo_threshold fairly high b) setting join_collapse_limit fairly high (assuming
>all the above join targets are tables and not views, setting it to something like 25 should do the trick.
I did try various combinations of these settings but none yielded any significant query run time improvements.
> You also haven't told us what settings you have for things like effective_cache_size, which can dramatically affect query plans.
effective_cache_size = 4096MB
I tried bumping this up as well but again no significant query run time improvements.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marco Di Cesare | 2014-10-21 20:06:58 | Re: Query with large number of joins |
| Previous Message | Igor Neyman | 2014-10-21 19:53:48 | Re: extremly bad select performance on huge table |