From: Andrei Lepikhov <a.lepikhov@postgrespro.ru>
To: Alexander Korotkov <aekorotkov@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Richard Guo <guofenglinux@gmail.com>
Cc: Vik Fearing <vik@postgresfriends.org>
Cc: zuming.jiang@inf.ethz.ch, pgsql-bugs@lists.postgresql.org, Alexander Korotkov <akorotkov@postgresql.org>
Subject: Re: BUG #18170: Unexpected error: no relation entry for relid 3
Date: Thu, 2 Nov 2023 09:10:40 +0700
Message-ID: <c1acd685-c160-4b6a-ad67-610b02ca1d81@postgrespro.ru> (raw)
In-Reply-To: <CAPpHfdsnAbg8CaK+NJ8AkiG_+_Tt07eCStkb1LOa50f0UsT5RQ@mail.gmail.com>
References: <18170-f1d17bf9a0d58b24@postgresql.org>
<4ecab120-6be3-4cf6-a2a0-249c73ae91d4@postgresfriends.org>
<1189851.1698340331@sss.pgh.pa.us>
<011bcae5-7840-42c7-a50c-b406189e2e78@postgrespro.ru>
<CAPpHfdsiN0norSHfw3Ujemf=RuPzMxt5PRDiyv0vqUdwSBDtoA@mail.gmail.com>
<721542ce-79df-469e-93e9-811fadb5bd0c@postgrespro.ru>
<2eb87c2e-7e6f-4002-8df3-8fac3aa6a037@postgrespro.ru>
<CAMbWs494m3AjhHry_HFCFi_SJ+6-PaeMRbx7jK39ZHmK0MVOUA@mail.gmail.com>
<1551957.1698417686@sss.pgh.pa.us>
<CAPpHfdtU4Y=H-0MGHy6EzDvniSda46wG+_osh-2w5JWbnDZY0w@mail.gmail.com>
<CAPpHfdtzyf_7svV5KW8WgNUZMC4h1VqdbAZUO_OGgaJ74Q6ncA@mail.gmail.com>
<CAPpHfdsnAbg8CaK+NJ8AkiG_+_Tt07eCStkb1LOa50f0UsT5RQ@mail.gmail.com>
On 2/11/2023 05:29, Alexander Korotkov wrote:
> On Wed, Nov 1, 2023 at 12:29 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
>> On Sat, Oct 28, 2023 at 12:12 AM Alexander Korotkov
>> <aekorotkov@gmail.com> wrote:
>>>
>>> On Fri, Oct 27, 2023 at 5:41 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>> Richard Guo <guofenglinux@gmail.com> writes:
>>>>> Alternatively, can we look at subroot->parse->targetList instead of
>>>>> subquery->targetList where we call estimate_num_groups on the output of
>>>>> the subquery?
>>>>
>>>> Please read the comment just above that.
>>>
>>> Thank you, Tom, This is clear.
>>
>>
>> Hmm... I just found that I wasn't attentive enough. The proposed
>> change is to use subroot->parse->targetList, not
>> subroot->processed_tlist. I don't know what could be the problem
>> here.
>
> My proposal is to use the attached patch as a hotfix for the bug considered.
Looks good, no objections.
>
> And for future I propose to consider two questions (each should
> probably go to its own thread):
> 1) Getting rid of having two distinct copies of parse tree (have one
> copy instead).
+1. It can be done somewhere near the beta release. Or, in the next
release, with the sake of finding other issues (like fixing with the
patch proposed), if they have a place in the planner's code.
> 2) Introduce relation aliases to simplify self-join removal.
In my opinion, it should be another type of RelOptInfo, not a simple
reference to the entry that has been kept. And we need to invent a kind
of relid translation procedure. Would it be worth it? I'm not sure, but
it can make implementation of optimizations of that type simpler.
--
regards,
Andrei Lepikhov
Postgres Professional
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: a.lepikhov@postgrespro.ru, aekorotkov@gmail.com, tgl@sss.pgh.pa.us, guofenglinux@gmail.com, vik@postgresfriends.org, akorotkov@postgresql.org
Subject: Re: BUG #18170: Unexpected error: no relation entry for relid 3
In-Reply-To: <c1acd685-c160-4b6a-ad67-610b02ca1d81@postgrespro.ru>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox