Re: Check each of base restriction clauses for constant-FALSE-or-NULL
| От | Richard Guo |
|---|---|
| Тема | Re: Check each of base restriction clauses for constant-FALSE-or-NULL |
| Дата | |
| Msg-id | CAMbWs49D3AF7j23LUrg=j8U3M0Ppo2evDsV-GyLNypvJa+vW6Q@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Check each of base restriction clauses for constant-FALSE-or-NULL (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>) |
| Ответы |
Re: Check each of base restriction clauses for constant-FALSE-or-NULL
|
| Список | pgsql-hackers |
On Mon, Oct 9, 2023 at 5:48 PM Ashutosh Bapat <ashutosh.bapat.oss@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().
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().
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
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
В списке pgsql-hackers по дате отправления: