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  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Список 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().
 
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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: Re: On login trigger: take three
Следующее
От: Ashutosh Bapat
Дата:
Сообщение: Re: Check each of base restriction clauses for constant-FALSE-or-NULL