Re: BUG #18170: Unexpected error: no relation entry for relid 3

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