Re: Postgres undeterministically uses a bad plan, how to convince it otherwise? - Mailing list pgsql-general

From cen
Subject Re: Postgres undeterministically uses a bad plan, how to convince it otherwise?
Date
Msg-id 01101f47-e596-cc72-cd7c-d9d027c9b9ef@gmail.com
Whole thread Raw
In response to Re: Postgres undeterministically uses a bad plan, how to convince it otherwise?  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: Postgres undeterministically uses a bad plan, how to convince it otherwise?  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-general
> Likely to be safe, you'd just include both. The problem is that the
> query planner makes use of equivalence classes to deduce equivalence
> in quals.
>
> If you have a query such as:
>
> select * from t1 inner join t2 on t1.x = t2.y where t1.x = 3;
>
> then the planner can deduce that t2.y must also be 3 and that qual can
> be pushed down to the scan level. If t2.y = 3 is quite selective and
> there's an index on that column, then this deduction is likely going
> to be a very good win, as the alternative of not using it requires
> looking at all rows in t2.

Does equivalency only work for constants as in the sample you provided 
or will it also be found in b1."number" and t0."block_number" in my 
sample query?

Meaning the columns could be used interchangeably in all the WHERE 
clauses and the ORDER clause, then it is a matter of figuring out what 
costs less.






pgsql-general by date:

Previous
From: Alban Hertroys
Date:
Subject: Re: DISTINCT *and* ORDER BY in aggregate functions on expressions(!)y
Next
From: David Rowley
Date:
Subject: Re: Postgres undeterministically uses a bad plan, how to convince it otherwise?