Re: foreign join error "variable not found in subplan target list"
Richard Guo <guofenglinux@gmail.com>
From: Richard Guo <guofenglinux@gmail.com>
To: Etsuro Fujita <etsuro.fujita@gmail.com>
Cc: Alexander Pyhalov <a.pyhalov@postgrespro.ru>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2022-09-13T02:28:42Z
Lists: 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
Commits
-
postgres_fdw: Avoid 'variable not found in subplan target list' error.
- d4adff0e97f0 10.23 landed
- 07d81d1e5b75 11.18 landed
- 87fd3c9025da 12.13 landed
- 6749d4e8c71b 13.9 landed
- b53d104ae3b9 14.6 landed
- 64387c540805 15.0 landed
- 9320cfdd06e5 16.0 landed