Re: Check each of base restriction clauses for constant-FALSE-or-NULL

On Mon, Oct 9, 2023 at 5:48 PM Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
wrote:

> postgres(at)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