Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.1\))
Subject: Re: BUG #18905: The opposite WHERE clause intersects and is always an
 empty set. It should perform no action.
From: Christophe Pettus <xof@thebuild.com>
In-Reply-To: <tencent_47C0CAC405AB8FF03DADC3B5ED82151EF506@qq.com>
Date: Sun, 27 Apr 2025 12:19:59 -0700
Cc: "David G. Johnston" <david.g.johnston@gmail.com>,
 "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2D956CA2-F876-48BA-B12E-FB9FD81F4AE5@thebuild.com>
References: <18905-f17e775841805cda@postgresql.org>
 <CAKFQuwZQB2=CRdqd1rT8cs+ziUjnDCbbnNot-UzyMBypDUkA+A@mail.gmail.com>
 <tencent_47C0CAC405AB8FF03DADC3B5ED82151EF506@qq.com>
To: =?utf-8?B?6LWW6ZSm6L6J?= <jh.lai@qq.com>
Archived-At: 
 <https://www.postgresql.org/message-id/2D956CA2-F876-48BA-B12E-FB9FD81F4AE5%40thebuild.com>
Precedence: bulk


> On Apr 27, 2025, at 10:54, =E8=B5=96=E9=94=A6=E8=BE=89 <jh.lai@qq.com> =
wrote:
> But I don't believe this optimization is meaningless.

I don't believe anyone claims this is "meaningless."

Every condition the planner has to check for adds complexity and time to =
the planner.  If this will provide a significant improvement in plans =
for a reasonable number of real-life cases, then it might well be worth =
it.  This is especially true when there is no way of writing the query =
without running into the issue.

However, many proposed improvements optimize for a relatively uncommon =
case, but would add time and complexity for all queries.  In this case, =
it appears that this case is relatively uncommon, and it can be easily =
fixed by rewriting the query.  Given that the project does not have =
infinite resources to dedicate to planner improvements, it does not seem =
to be an area that would reward the work put into it.=