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 CAMbWs486Cwp+WiH4i4Us+sdXSUiMpHcAqNEfS0Gfn4AXEVeNeg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Check each of base restriction clauses for constant-FALSE-or-NULL  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: Check each of base restriction clauses for constant-FALSE-or-NULL  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers

On Tue, Oct 10, 2023 at 5:10 PM David Rowley <dgrowleyml@gmail.com> wrote:
On Sat, 7 Oct 2023 at 22:44, Richard Guo <guofenglinux@gmail.com> wrote:
>
> In relation_excluded_by_constraints() when we're trying to figure out
> whether the relation need not be scanned, one of the checks we do is to
> detect constant-FALSE-or-NULL restriction clauses.  Currently we perform
> this check only when there is exactly one baserestrictinfo entry, and
> the comment explains this as below.
>
>  * Regardless of the setting of constraint_exclusion, detect
>  * constant-FALSE-or-NULL restriction clauses.  Because const-folding will
>  * reduce "anything AND FALSE" to just "FALSE", any such case should
>  * result in exactly one baserestrictinfo entry.

Coincidentally (?), I saw the same thing just a few weeks ago while
working on [1].  I made the exact same adjustment to the code in
relation_excluded_by_constraints() as you have.

Haha, I noticed the need of this change while writing v5 patch [1] for
that same thread.  That patch generates a new constant-FALSE
RestrictInfo for an IS NULL qual that can be reduced to FALSE, and this
makes the comment in relation_excluded_by_constraints() about 'any such
case should result in exactly one baserestrictinfo entry' not true any
more.  Without this change in relation_excluded_by_constraints(), a
query like below would not be able to be marked as dummy.

    select * from t where a is null and 'otherquals';

And then the regression test diff after applying this change reminds me
that equivclass.c may also generate new constant-FALSE RestrictInfos on
the fly, so it seems to me that this change may benefit some queries
even without the 'reduce-NullTest' patch.
 
I wasn't really expecting the baserestrictinfo list to be excessively
long, and if it ever was, I think looking at things like selectivity
estimations would by far drown out looping over the entire list in
relation_excluded_by_constraints() rather than just looking at the
first item in the list.

Agreed.
 
After making the change, I saw the same regression test change as you
did, but didn't really feel like it was worth tackling separately from
the patch that we were working on.

I was thinking that this change may be worthwhile by itself even without
the 'reduce-NullTest' patch, because it can benefit some cases, such as
where EC generates constant-FALSE on the fly.  So maybe it's worth a
separate patch?  I'm not quite sure.

[1] https://www.postgresql.org/message-id/CAMbWs4-eNVNTNc94eF%2BO_UwHYKv43vyMurhcdqMV%3DHt5fehcOg%40mail.gmail.com

Thanks
Richard

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

Предыдущее
От: vignesh C
Дата:
Сообщение: Re: Making aggregate deserialization (and WAL receive) functions slightly faster
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: pg_resetwal: Corrections around -c option