postgres@312571=# explain (analyze, costs off) select * from pg_class t1 where oid = 1 and oid = 2; QUERY PLAN --------------------------------------------------------------------------- Result (actual time=0.002..0.003 rows=0 loops=1) One-Time Filter: false -> Index Scan using pg_class_oid_index on pg_class t1 (never executed) Index Cond: (oid = '1'::oid) Planning Time: 0.176 ms Execution Time: 0.052 ms (6 rows)
You will see that the scan node was never executed. Hence there's no execution time benefit if we remove the scan plan.
Yeah, the constant-FALSE is a pseudoconstant qual and will result in a gating Result node atop the scan node. So this optimization about detecting constant-FALSE restriction clauses and marking the rel as dummy if there is one is not likely to benefit execution time. AFAICS it can help save some planning efforts, because once a base rel is marked dummy, we won't bother building access paths for it. Also a dummy input rel can save efforts when we generate paths for joinrel, see how we cope with dummy rels in populate_joinrel_with_paths().
Where do we produce the single baserestrictinfo mentioned in the comments? Is it before the planning proper starts?
Do you mean the const-folding? It happens in the preprocessing phase, specifically in eval_const_expressions().
get_gating_quals does what you are doing much earlier in the query processing. Your code would just duplicate that.
Hm, I don't think so. get_gating_quals is called in createplan.c, where we've selected the best path, while the optimization with my code happens much earlier, when we set size estimates for a base relation. Neither of these two is a duplicate of the other. I think the theory here is that it's always a win to mark a rel as dummy if possible as early as we can.
