public inbox for pgsql-bugs@postgresql.org
help / color / mirror / Atom feedFrom: Andrei Lepikhov <lepihov@gmail.com>
To: Alexander Korotkov <aekorotkov@gmail.com>
To: Tender Wang <tndrwang@gmail.com>
Cc: Kirill Reshke <reshkekirill@gmail.com>
Cc: Fujii Masao <masao.fujii@gmail.com>
Cc: ammmkilo@163.com
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #19435: Error: "No relation entry for relid 2" Triggered by Complex Join with Self-Referencing Tables
Date: Fri, 22 May 2026 12:16:17 +0200
Message-ID: <42e88e4b-0958-49a3-b32c-b61f9eec8da0@gmail.com> (raw)
In-Reply-To: <CAPpHfdseh9h2NSFyjWbuhoik61Ao7J0AjbuZBd_Fz+gKz98j5Q@mail.gmail.com>
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>
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
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: lepihov@gmail.com, aekorotkov@gmail.com, tndrwang@gmail.com, reshkekirill@gmail.com, masao.fujii@gmail.com, ammmkilo@163.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #19435: Error: "No relation entry for relid 2" Triggered by Complex Join with Self-Referencing Tables
In-Reply-To: <42e88e4b-0958-49a3-b32c-b61f9eec8da0@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox