Re: Query with large number of joins - Mailing list pgsql-performance

From Marco Di Cesare
Subject Re: Query with large number of joins
Date
Msg-id 82791b1473d3440bb4381bf81f448471@CO2PR0701MB759.namprd07.prod.outlook.com
Whole thread Raw
In response to Re: Query with large number of joins  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
Andrew Dunstan <andrew@dunslane.net> writes:
> 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.

Tom Lane < tgl@sss.pgh.pa.us> writes:
> You'd have to do both, I think, to get an exhaustive plan search.

>In any case, this query is going to result in full table scans of most of the tables, because there just aren't very
manyWHERE constraints; so > 
>expecting it to run instantaneously is a pipe dream.  I'm not sure that there's a significantly better plan to be had.

>            regards, tom lane

I get that same feeling. Just wanted to be sure there was nothing obvious in terms of settings we might have missed.

The BI tool we use wants to load as much raw data as needed and then apply filters (where clauses) on top of that. The
numerousjoins support those filters and a good number of those joins are one-to-many tables causing a Cartesian
product. 


pgsql-performance by date:

Previous
From: Marco Di Cesare
Date:
Subject: Re: Query with large number of joins
Next
From: Igor Neyman
Date:
Subject: Re: Query with large number of joins