Re: Some optimizations for COALESCE expressions during constant folding
| От | Tender Wang |
|---|---|
| Тема | Re: Some optimizations for COALESCE expressions during constant folding |
| Дата | |
| Msg-id | CAHewXNkpN2tUaQDHFqZFcBJda-UccSgXiZO+p+5yyL6S69_J7g@mail.gmail.com обсуждение исходный текст |
| Ответ на | Some optimizations for COALESCE expressions during constant folding (Richard Guo <guofenglinux@gmail.com>) |
| Список | pgsql-hackers |
Richard Guo <guofenglinux@gmail.com> 于2025年11月25日周二 18:51写道:
Currently, we perform some simplification for Const arguments of a
COALESCE expression. For instance, if the first argument is a
non-null constant, we use that constant as the result for the entire
expression. If a subsequent argument is a non-null constant, all
following arguments are dropped since they will never be reached.
We can extend this simplification to Var arguments since the NOT NULL
attribute information is now available during constant folding. 0001
implements this.
I took a quick look at the 0001. It seems correct to me.
One thing I want to confirm is that if var_is_nonnullable() returns true, we can make sure that
the Var is 100% nonnullable, no matter what kind of join reorder happens.
Another optimization that can be done for a COALESCE expression is
when it is used in a NullTest. We can determine that a COALESCE
expression is non-nullable by checking if at least one of its
arguments is proven non-null. This information can then be used to
reduce the NullTest qual to a constant true or false. 0002 implements
this. (I'm wondering whether it'd be better to consolidate the
non-null check for Const, Var, and CoalesceExpr into one helper
function to simplify the code in eval_const_expressions.)
I have no objections to the 0002 code logic.
But I wonder how often users write "COALECE() is not null" in their query.
Before this patch, I didn't find the case in the regression test cases.
Thanks,
Tender Wang
В списке pgsql-hackers по дате отправления: