Re: Optimize IS DISTINCT FROM with non-nullable inputs - Mailing list pgsql-hackers

From Tender Wang
Subject Re: Optimize IS DISTINCT FROM with non-nullable inputs
Date
Msg-id CAHewXNmwezkw4a_KbcmqX8n_+SsDEJWUPd8PKG--naDb_Vf7UA@mail.gmail.com
Whole thread Raw
In response to Re: Optimize IS DISTINCT FROM with non-nullable inputs  (Richard Guo <guofenglinux@gmail.com>)
List pgsql-hackers
Richard Guo <guofenglinux@gmail.com> 于2026年1月28日周三 14:42写道:
>
> On Tue, Jan 27, 2026 at 4:10 PM Richard Guo <guofenglinux@gmail.com> wrote:
> > On Tue, Jan 27, 2026 at 11:32 AM Tender Wang <tndrwang@gmail.com> wrote:
> > > 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.
>
> > Well, while it's true that the parser would do this transformation for
> > "literal" NULLs, here we are talking more about "calculated" NULLs.
> > Consider "not_null_col IS DISTINCT FROM (1 + NULL)".
>
> BTW, this reminds me that we can teach const-folding to always
> transform "x IS [NOT] DISTINCT FROM NULL" to a NullTest, even when x
> cannot be proven non-nullable.  (The parser have already done that for
> literal NULLs.)

Yeah, this transformation can enable the planner to reduce outer joins
to plain joins.


> Please see 0003 for the details of this transformation.

The v3 patches LGTM.



--
Thanks,
Tender Wang



pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: Implement waiting for wal lsn replay: reloaded
Next
From: Dilip Kumar
Date:
Subject: Re: unnecessary executor overheads around seqscans