Re: [PERFORM] Inaccurate Explain Cost

Edson Richter <edsonrichter(at)hotmail(dot)com> 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