Hi,
Richard Guo <[email protected]> 于2026年1月26日周一 16:00写道：
>
> On Fri, Jan 23, 2026 at 10:40 PM Richard Guo <[email protected]> wrote:
> > I'm kind of concerned about whether there are edge cases where this
> > transformation is not safe, specifically regarding "rowtype" inputs.
>
> After a second thought, I think this should be safe even for "rowtype"
> inputs. The executor (ExecInterpExpr) evaluates a DistinctExpr with
> non-null inputs by simply applying the underlying equality function
> and then negating the result. Also, record_eq explicitly treats two
> NULLs as equal. Therefore, in this case, converting IS DISTINCT FROM
> to the inequality operator in the planner produces the exact same
> behavior as the executor.
>
> Also, I think we can play this same trick with BooleanTest (IS [NOT]
> TRUE/FALSE/UNKNOWN). A BooleanTest treats a NULL input as the logical
> value "unknown". If we know that the input can not be NULL, we can
> simplify it directly to a boolean expression or a constant. Please
> see 0002.
>
> - Richard
Interesting optimization. I look through the v2-0001 patch. In the
commit message, it says:
...
This patch extends the optimization to cases where inputs are non-constant but
proven to be non-nullable. Specifically, "x IS DISTINCT FROM NULL"
folds to constant TRUE if "x" is known to be non-nullable.
...
But I found that the case "x IS DISTINCT FROM NULL" is converted to
NullTest in transformAExprDistinct().
It will be optimized in the "case T_NullTest:" not by this patch.
The test case can't cover the following codes:
+ /*
+ * If one input is an explicit
NULL constant, and the
+ * other is a non-nullable
expression, the result is
+ * always TRUE.
+ */
+ if (has_null_input)
+ return
makeBoolConst(true, false);
And I adjusted a little above code to check if all regression tests
can enter above if,
if (has_null_input)
{
assert(0);
return makeBoolConst(true, false);
}
All tests pass; no crashes occurred.
--
Thanks,
Tender Wang
