Re: BUG #18905: The opposite WHERE clause intersects and is always an empty set. It should perform no action.

From: Christophe Pettus <xof(at)thebuild(dot)com>
To: 赖锦辉 <jh(dot)lai(at)qq(dot)com>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #18905: The opposite WHERE clause intersects and is always an empty set. It should perform no action.
Date: 2025-04-27 19:19:59
Message-ID: 2D956CA2-F876-48BA-B12E-FB9FD81F4AE5@thebuild.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> On Apr 27, 2025, at 10:54, 赖锦辉 <jh(dot)lai(at)qq(dot)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.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message marcos sicat 2025-04-27 20:51:10 Postgres 17.4 is much slower than Postgres 15.12 using RECURSIVE
Previous Message Tom Lane 2025-04-27 18:02:36 Re: BUG #18904: INTERSECT with an impossible where should eliminate both from the query plan