Обсуждение: Some optimizations for COALESCE expressions during constant folding
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. 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.) - Richard
Вложения
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
Re: Some optimizations for COALESCE expressions during constant folding
От
Dagfinn Ilmari Mannsåker
Дата:
Richard Guo <guofenglinux@gmail.com> writes:
> + ListCell *lc;
> +
> + foreach(lc, coalesceexpr->args)
> + {
> + Node *coalescearg = (Node *) lfirst(lc);
I have no comment on the rest of the patch, but this could be simplifed
using the foreach_ptr macro:
foreach_ptr(Node, coalescearg, coalesceexpr->args)
{
- ilmari
On Tue, 25 Nov 2025 at 23:51, Richard Guo <guofenglinux@gmail.com> wrote: > (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.) uhh, of course it is. That's what I did in [1] for Consts and expand expr_is_nonnullable() to support COALESCE exprs then modify eval_const_expressions_mutator() to use that rather than using var_is_nonnullable(). That way we'll not need to modify the constant folding code every time we think of something new that we can prove can't be NULL. David [1] https://www.postgresql.org/message-id/attachment/184166/v3-0001-Have-the-planner-replace-COUNT-ANY-with-COUNT-whe.patch
On Wed, 26 Nov 2025 at 02:10, David Rowley <dgrowleyml@gmail.com> wrote: > > On Tue, 25 Nov 2025 at 23:51, Richard Guo <guofenglinux@gmail.com> wrote: > > (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.) > > uhh, of course it is. That's what I did in [1] for Consts and expand > expr_is_nonnullable() to support COALESCE exprs then modify > eval_const_expressions_mutator() to use that rather than using > var_is_nonnullable(). That way we'll not need to modify the constant > folding code every time we think of something new that we can prove > can't be NULL. That one failed the copy/edit pass. Here's another try at getting my point across: uhh, of course it is. That's what I did in [1] for Consts. Doing it this way means we'll not need to modify the constant folding code (or whichever other code wants to know when an Expr can't be NULL) every time we think of something new that we can prove can't be NULL. David [1] https://www.postgresql.org/message-id/attachment/184166/v3-0001-Have-the-planner-replace-COUNT-ANY-with-COUNT-whe.patch