Edson Richter <edsonrichter@xxxxxxxxxxx> writes: >> That said, looking at your actual query: >> >> SELECT COUNT(DISTINCT eu.id) >> FROM exchange_uploads eu >> JOIN upload_destinations ud ON ud.id = eu.upload_destination_id >> LEFT JOIN uploads u ON u.id = eu.upload_id >> LEFT JOIN import_errors ie ON ie.exchange_upload_id = eu.id >> LEFT JOIN exchanges e ON e.id = ud.exchange_id >> WHERE eu.created_at >= '2012-07-27 21:21:57.363944' >> AND ud.office_id = 6; >> >> Doesn't need half of these joins. They're left joins, and never used >> in the query results or where criteria. You could just use this: > Interesting. I've similar situation, where user can choose a set of > filters, and then the query must have several left joins "just in case" > (user need in the filer). > I know other database that is able to remove unnecessary outer joins > from queries when they are not relevant and for instance become faster. > Can't PostgreSQL do the same? It does, and did - note the query plan is only scanning 3 of the 5 tables mentioned in the query. (The other left join appears to be to a non-unique column, which makes it not redundant.) regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
