Re: why is a constraint not 'pushed down' into a subselect when this subselect is using a 'group by' ??

Frank van Vugt <ftm(dot)van(dot)vugt(at)foxi(dot)nl> writes:
> When the 'article.id < 50' constraint is added, it follows that
> 'foo.article_id < 50' is a constraint as well. Why is this constraint not
> used to avoid the seqscan on package?

We don't attempt to make every possible inference (and I don't think
you'd like it if we did). The current code will draw inferences about
transitive equality, for instance given a = b and b = c it will infer
a = c, if all three operators involved are mergejoinable. But given
a = b and some arbitrary other constraint on b, it won't consider
substituting a into that other constraint. This example doesn't
persuade me that it would be worth expending the cycles to do so.

Aside from the sheer cost of planning time, there are semantic
pitfalls to consider. In some datatypes there are values that are
"equal" according to the = operator but are distinguishable by other
operators --- for example, zero and minus zero in IEEE-standard
float arithmetic. We'd need a great deal of caution in determining
what inferences can be drawn.

regards, tom lane