Re: [Patch] optimizer - simplify $VAR1 IS NULL AND $VAR1 IS NOT NULL

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [Patch] optimizer - simplify $VAR1 IS NULL AND $VAR1 IS NOT NULL
Дата
Msg-id 15585.1573065242@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [Patch] optimizer - simplify $VAR1 IS NULL AND $VAR1 IS NOT NULL  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Список pgsql-hackers
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Pierre" == Pierre Ducroquet <p.psql@pinaraf.info> writes:
>  Pierre> The attached patch handles both situations. When flattening and
>  Pierre> simplifying the AND clauses, a list of the NullChecks is built,
>  Pierre> and subsequent NullChecks are compared to the list. If opposite
>  Pierre> NullChecks on the same variable are found, the whole AND is
>  Pierre> optimized away.

> That's all very well but it's very specific to a single use-case. The
> existing code, when you enable it, can detect a whole range of possible
> refutations (e.g. foo > 1 AND foo < 1).

Yeah.  Just for the record, if we were interested in taking a patch
for this purpose, simplify_and_arguments is a poor choice of where
to do it anyway.  That would only find contradictions between clauses
that were in the same expression at eval_const_expressions time, which
is pretty early and will miss a lot of logically-equivalent situations
(e.g. if one clause is in a JOIN...ON and the other is in WHERE).
The constraint exclusion code looks for contradictions between clauses
that have been pushed down to the same relation during jointree
deconstruction, ie they have the same set of referenced relations.
That would be a much better place for this type of logic.

            regards, tom lane



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

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: idea: log_statement_sample_rate - bottom limit for sampling
Следующее
От: Adrien Nayrat
Дата:
Сообщение: Re: Log statement sample - take two