Re: BUG #17885: slow planning constraint_exclusion

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: BUG #17885: slow planning constraint_exclusion
Дата
Msg-id CAApHDvrsvM-6p07je7rM0xE+iMXdvCWUXJKBrNgL-JyoF0cePQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #17885: slow planning constraint_exclusion  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: BUG #17885: slow planning constraint_exclusion  (Maxim Boguk <maxim.boguk@gmail.com>)
Список pgsql-bugs
On Wed, 5 Apr 2023 at 10:16, David Rowley <dgrowleyml@gmail.com> wrote:
> We still run relation_excluded_by_constraints() after partition
> pruning only the remaining partitions.  I believe there were some
> cases that we still didn't prune that relation_excluded_by_constraints
> was able to eliminate. I don' recall the exact details of what those
> cases are. I believe the call to relation_excluded_by_constraints()
> was kept due to this.

I may have misremembered that.  On digging further, it seems we don't
run relation_excluded_by_constraints() using the partition constraint.
That's fairly evident by looking at the code and also noticing that we
don't prune partitions with partition_pruning=off.

The extra time is being spent checking the base quals don't refute
each other.  That's able to determine that something like the
following can't return anything:

postgres=# explain select * from part_test where col_a = col_b and
col_a <> col_b;
                QUERY PLAN
------------------------------------------
 Result  (cost=0.00..0.00 rows=0 width=0)
   One-Time Filter: false
(2 rows)

Same recommendation as before - if you don't want it, just turn it off.

David



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

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: BUG #17885: slow planning constraint_exclusion
Следующее
От: Maxim Boguk
Дата:
Сообщение: Re: BUG #17885: slow planning constraint_exclusion