Message-ID: <42e88e4b-0958-49a3-b32c-b61f9eec8da0@gmail.com>
Date: Fri, 22 May 2026 12:16:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: BUG #19435: Error: "No relation entry for relid 2" Triggered by
 Complex Join with Self-Referencing Tables
To: Alexander Korotkov <aekorotkov@gmail.com>,
 Tender Wang <tndrwang@gmail.com>
Cc: Kirill Reshke <reshkekirill@gmail.com>,
 Fujii Masao <masao.fujii@gmail.com>, ammmkilo@163.com,
 pgsql-bugs@lists.postgresql.org
References: <19435-3cc1a87f291129f1@postgresql.org>
 <CAPpHfdv6gzSTXHJxYSgB8sULadXM4wvhgoQODaOxYCJfagKNPw@mail.gmail.com>
 <CAHewXN=7kDJjUcgEm+6qhaKOXuqzvhRqAAKdafNCRgn0yH7BGg@mail.gmail.com>
 <CAHewXNm5OOREJ8wZ1cLJdQz7O1aQ0E1RBB55S6O138K8vBdc9g@mail.gmail.com>
 <CAPpHfducqLJ=o3LkoPKGfZJVQuuei+P=2oUF6hX6rzHTZSxoyA@mail.gmail.com>
 <a78fe5d4-e6b8-4b3c-9cfd-135edbb68e4c@gmail.com>
 <CAPpHfduTWFCHaK8U7bDfYid5pjVA=FHG1b0nTEMFqFKHebGJxQ@mail.gmail.com>
 <a498f5b8-2f17-4ee0-b021-63ff9829b45b@gmail.com>
 <CALdSSPhpUdY7-5Zg38oS1uRtu5iTFzdo0R7Z2YZD603M9RpJxg@mail.gmail.com>
 <5a039d60-d13b-4cf0-a807-9c7269f06831@gmail.com>
 <CAPpHfdsyNYEbjjLdsa8i8Ds-5=4pFif1+uCHn3vwzx2Pq5y29A@mail.gmail.com>
 <CAPpHfdsrmAg+aqpjAF4Fdp2c59-dFmwBuNLhNqrxzTguiAKf=w@mail.gmail.com>
 <afb2c07f-05b7-403c-b10c-ca7390316e94@gmail.com>
 <CAHewXNnt5bSWUirqV7mtkCit592j3h7VA-gOOJW_Ms0x8zv62w@mail.gmail.com>
 <CAPpHfdseh9h2NSFyjWbuhoik61Ao7J0AjbuZBd_Fz+gKz98j5Q@mail.gmail.com>
Content-Language: en-US
From: Andrei Lepikhov <lepihov@gmail.com>
In-Reply-To: 
 <CAPpHfdseh9h2NSFyjWbuhoik61Ao7J0AjbuZBd_Fz+gKz98j5Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/42e88e4b-0958-49a3-b32c-b61f9eec8da0%40gmail.com>
Precedence: bulk

On 22/04/2026 17:10, Alexander Korotkov wrote:
> On Fri, Mar 27, 2026 at 3:19 AM Tender Wang <tndrwang@gmail.com> wrote:
>>> but I'm unsure, in general, that this approach is conservative enough.
>>> Maybe we shouldn’t change this logic and invent one more optimisation
>>> ‘deduplication’ stage later, before the selectivity estimation stage.
> 
> I have another approach about to deduplication of RestrictInfo's.  The
> field, which differs in this case, is outer_relids.  AFAICS,
> outer_relids and incompatible_relids serves as the restriction on what
> we can do with RestrictInfo.  So, what we can do is to ignore both
> outer_relids and incompatible_relids during comparison, but compose a
> union of their values for remaining RestrictInfo.  That means that
> remaining RestrictInfo will ancest all the restrictions, and that
> should be safe.
> 
> What do you think?

Thank you for all the work you’ve put into de-duplicating clauses.

I agree that using the union of outer_relids and incompatible_relids is the
strictest common constraint. There shouldn’t be any issues, so this approach
should work.

However, the new function relies on a hand-picked list of "semantic" fields. If
someone adds another field to RestrictInfo, this function could break without
warning unless they remember to update it. We should add comment hooks that say,
"If you add a field here, update analyzejoins.c too."

Also, de-duplication happens in several places. If we change the logic in
add_non_redundant_clauses, maybe we should review the update_eclasses() code as
well.

-- 
regards, Andrei Lepikhov,
pgEdge