On Mon, Oct 9, 2023 at 5:48 PM Ashutosh Bapat <ashutosh.bapat....@gmail.com> wrote:
> 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. Thanks Richard
