Martijn van Oosterhout <kleptog@svana.org> writes:
> 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.
> Ideally, you could create a new node would has a RangeTable (I think that's
> the right term) but produces no output.
We already use Result nodes with resconstantqual qualifiers to handle
gating of execution of entire subplans (see query_planner()). It might
be worth thinking about whether that concept is useful to apply at lower
levels of a plan tree.
regards, tom lane