pgsql: Teach optimizer's predtest.c more things aboutScalarArrayOpExpr

Поиск
Список
Период
Сортировка
От Tom Lane
Тема pgsql: Teach optimizer's predtest.c more things aboutScalarArrayOpExpr
Дата
Msg-id E1gzqQE-0007DZ-KX@gemulon.postgresql.org
обсуждение исходный текст
Список pgsql-committers
Teach optimizer's predtest.c more things about ScalarArrayOpExpr.

In particular, make it possible to prove/refute "x IS NULL" and
"x IS NOT NULL" predicates from a clause involving a ScalarArrayOpExpr
even when we are unable or unwilling to deconstruct the expression
into an AND/OR tree.  This avoids a former unexpected degradation of
plan quality when the size of an ARRAY[] expression or array constant
exceeded the arbitrary MAX_SAOP_ARRAY_SIZE limit.  For IS-NULL proofs,
we don't really care about the values of the individual array elements;
at most, we care whether there are any, and for some common cases we
needn't even know that.

The main user-visible effect of this is to let the optimizer recognize
applicability of partial indexes with "x IS NOT NULL" predicates to
queries with "x IN (array)" clauses in some cases where it previously
failed to recognize that.  The structure of predtest.c is such that a
bunch of related proofs will now also succeed, but they're probably
much less useful in the wild.

James Coleman, reviewed by David Rowley

Discussion: https://postgr.es/m/CAAaqYe8yKSvzbyu8w-dThRs9aTFMwrFxn_BkTYeXgjqe3CbNjg@mail.gmail.com

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/65ce07e0202f2ef0953be9d085d3e5df7ad353a4

Modified Files
--------------
src/backend/optimizer/util/predtest.c              | 126 ++++++++--
.../test_predtest/expected/test_predtest.out       | 257 +++++++++++++++++++++
.../modules/test_predtest/sql/test_predtest.sql    | 115 +++++++++
3 files changed, 478 insertions(+), 20 deletions(-)


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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: pgsql: Fix whitespace
Следующее
От: Tom Lane
Дата:
Сообщение: pgsql: Check we don't misoptimize a NOT IN where the subquery returnsn