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-29 08:48:12
Message-ID: CAHewXNmwezkw4a_KbcmqX8n_+SsDEJWUPd8PKG--naDb_Vf7UA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Richard Guo <guofenglinux(at)gmail(dot)com> 于2026年1月28日周三 14:42写道:
>
> On Tue, Jan 27, 2026 at 4:10 PM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
> > On Tue, Jan 27, 2026 at 11:32 AM Tender Wang <tndrwang(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2026-01-29 09:24:58 Re: unnecessary executor overheads around seqscans
Previous Message Alexander Korotkov 2026-01-29 07:47:46 Re: Implement waiting for wal lsn replay: reloaded