> > One optimisation is for the query planner to drop tables whose output do not
> > affect the final result (where the WHERE clauses and the CHECK constraints
> > prove that no rows can be returned). While this is not the case for simple
> > queries, when involving views and inheritance it's very easy to do.
>
> Under what conditions is this actually going to buy you anything?
>
> Indexscans with self-contradictory index conditions, for example, fall
> through quite quickly already (look at the scan startup logic in nbtree.c).
> I'm not sure that there's any gain in having the planner duplicate that
> effort.
It covers cases that have check constraints on columns without an index, or
that have an index, but another index is chosen by the planner because it
looks cheaper. Maybe part of the startup logic in nbtree.c can be moved to
the planner, so it covers more cases and is not duplicated ?
There is a question whether this is useful for normal table access, since
most applications won't query on values that are not allowed. But for views
(especially union all) and inheritance it would imho certainly be very valuable.
Andreas