Re: foreign join error "variable not found in subplan target list"
От | Richard Guo |
---|---|
Тема | Re: foreign join error "variable not found in subplan target list" |
Дата | |
Msg-id | CAMbWs49+6WV5VLuZVeW4SJazbZ9nOU3OyD_XMS1MO4cQtCvY4A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: foreign join error "variable not found in subplan target list" (Etsuro Fujita <etsuro.fujita@gmail.com>) |
Ответы |
Re: foreign join error "variable not found in subplan target list"
|
Список | pgsql-bugs |
On Mon, Sep 12, 2022 at 12:19 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
On Wed, Aug 31, 2022 at 6:52 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
> On Wed, Aug 31, 2022 at 6:27 PM Richard Guo <guofenglinux@gmail.com> wrote:
> > Hmm, yes, the EPQ path does not need to compete with others in add_path,
> > so its cost does not matter too much. And the comment just above
> > GetExistingLocalJoinPath says:
> >
> > * Since the plan created using this path will presumably only be used to
> > * execute EPQ checks, efficiency of the path is not a concern.
> >
> > But still I feel it's not a good practice to not update the cost and
> > width fields after calling add_new_columns_to_pathtarget(). How about we
> > add some comments here explaining why we do not need to adjust the
> > estimates for the EPQ path?
>
> I agree with you on that point. I’ll update the patch as such in the
> next version.
Here is an updated patch for that. Other changes:
* I modified the patch so that we adjust the tlist of the EPQ path if
necessary, using the idea discussed upthread.
* I tweaked other comments a little bit.
+1. The new patch looks good to me.
Thanks
Richard
Thanks
Richard
В списке pgsql-bugs по дате отправления: