Re: Postgres undeterministically uses a bad plan, how to convince it otherwise?

> 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.