Andrew Dunstan <and...@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 < t...@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 many WHERE 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 numerous joins support those filters and a good number of those joins are one-to-many tables causing a Cartesian product. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
