| 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
| 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 |