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

Поиск
Список
Период
Сортировка
От Alexander Korotkov
Тема Re: BUG #18170: Unexpected error: no relation entry for relid 3
Дата
Msg-id CAPpHfdsnAbg8CaK+NJ8AkiG_+_Tt07eCStkb1LOa50f0UsT5RQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #18170: Unexpected error: no relation entry for relid 3  (Alexander Korotkov <aekorotkov@gmail.com>)
Ответы Re: BUG #18170: Unexpected error: no relation entry for relid 3  (Andrei Lepikhov <a.lepikhov@postgrespro.ru>)
Список pgsql-bugs
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.

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).
2) Introduce relation aliases to simplify self-join removal.

Any thoughts?

------
Regards,
Alexander Korotkov

Вложения

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #17552: pg_stat_statements tracks internal FK check queries when COPY used to load data
Следующее
От: PG Bug reporting form
Дата:
Сообщение: BUG #18177: certain queries under certain contexts take multiple orders of magnitude longer compared to v10