Message-ID: <c1acd685-c160-4b6a-ad67-610b02ca1d81@postgrespro.ru>
Date: Thu, 2 Nov 2023 09:10:40 +0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: BUG #18170: Unexpected error: no relation entry for relid 3
To: Alexander Korotkov <aekorotkov@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Richard Guo <guofenglinux@gmail.com>,
 Vik Fearing <vik@postgresfriends.org>, zuming.jiang@inf.ethz.ch,
 pgsql-bugs@lists.postgresql.org,
 Alexander Korotkov <akorotkov@postgresql.org>
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>
Content-Language: en-US
From: Andrei Lepikhov <a.lepikhov@postgrespro.ru>
Organization: Postgres Professional
In-Reply-To: 
 <CAPpHfdsnAbg8CaK+NJ8AkiG_+_Tt07eCStkb1LOa50f0UsT5RQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/c1acd685-c160-4b6a-ad67-610b02ca1d81%40postgrespro.ru>
Precedence: bulk

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