> Am I missing a situation where these joins could impact the result?
Yes it will impact the number of rows in the result. for example if foo is
empty then postgres is required to return no results, regardless of how many
rows are in bar. This is why it can ignore the table in the left join
— D
I noticed something peculiar while optimizing complex views today. The query
planner does not skip inner joins that, to my understanding, can have no impact
on the result. Am I missing a situation where these joins could impact the
result?
The following demonstrates the problem without the comp
Just to follow up on this...
Tried increasing stats targets last week + re-analyzing but the query was
just as bad.
Ended up increasing the prepareThreshold to prevent server-side prepares
for now (and thus later generic statements). This 'fixed' the issue and had
no noticeable negative effect for
Many thanks Justin & Jeff for your replies.
Presumbly the conditions are partially redundant, so loc_id => user_id
Yes you're right. I had overlooked this.
I've done some further testing and this confirms what you say: if the WHERE
columns are independent, then the Planner makes a reasonable es