Re: Evaluate expression at planning time for two more cases

Поиск
Список
Период
Сортировка
От Ashutosh Bapat
Тема Re: Evaluate expression at planning time for two more cases
Дата
Msg-id CAG-ACPXEfYXA3vz=e2KoNeP8JhC4C50ZtdeUyZFEsHR+_zyZKw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Evaluate expression at planning time for two more cases  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers


On Tue, 8 Sep 2020 at 07:16, Tom Lane <tgl@sss.pgh.pa.us> wrote:


I'm not sure what I think about Ashutosh's ideas about doing this
somewhere else than eval_const_expressions.  I do not buy the argument
that it's interesting to do this separately for each child partition.
Child partitions that have attnotnull constraints different from their
parent's are at best a tiny minority use-case, if indeed we allow them
at all (I tend to think we shouldn't). 

I agree about partitions. But, IMO, a child having constraints different from that of a parent is more common in inheritance trees.

Another point I raised in my mail was about constraint exclusion. Why aren't these clauses constant-folded by constraint exclusion? Sorry, I haven't looked at the constraint exclusion code myself for this.

As a not incidental example, consider

        select ... from t1 left join t2 on (...) where t2.x is not null;

reduce_outer_joins will realize that the left join can be reduced
to a plain join, whereupon (if t2.x is attnotnull) the WHERE clause
really is constant-true --- and this seems like a poster-child case
for it being useful to optimize away the WHERE clause.  But
we won't be able to detect that if we apply the optimization during
eval_const_expressions.  So maybe that's a good reason to do it
somewhere later.

+1 

--
Best Wishes,
Ashutosh

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Parallel worker hangs while handling errors.
Следующее
От: Ashutosh Bapat
Дата:
Сообщение: Re: Ideas about a better API for postgres_fdw remote estimates