Re: Optimize IS DISTINCT FROM with non-nullable inputs

From: Tender Wang <tndrwang(at)gmail(dot)com>
To: Richard Guo <guofenglinux(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Optimize IS DISTINCT FROM with non-nullable inputs
Date: 2026-01-27 02:32:25
Message-ID: CAHewXN=YuwkcJ8zk_TUSjDdfBjt+j-T8B2=dazJcoDxDxJ50mg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Richard Guo <guofenglinux(at)gmail(dot)com> 于2026年1月26日周一 16:00写道:
>
> On Fri, Jan 23, 2026 at 10:40 PM Richard Guo <guofenglinux(at)gmail(dot)com> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2026-01-27 02:39:00 Re: unnecessary executor overheads around seqscans
Previous Message Hayato Kuroda (Fujitsu) 2026-01-27 02:17:26 RE: Fix logical decoding not track transaction during SNAPBUILD_BUILDING_SNAPSHOT