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(at)gmail(dot)com> wrote:
>> On Sat, Oct 28, 2023 at 12:12 AM Alexander Korotkov
>> <aekorotkov(at)gmail(dot)com> wrote:
>>>
>>> On Fri, Oct 27, 2023 at 5:41 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> Richard Guo <guofenglinux(at)gmail(dot)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