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-08-31T09:26:58Z
Lists: pgsql-bugs
On Tue, Aug 30, 2022 at 3:50 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote: > On Mon, Aug 29, 2022 at 6:46 PM Richard Guo <guofenglinux@gmail.com> > wrote: > > I'm looking again on how we adjust the PathTarget, and I think we may > > need to update the cost and width fields if there are any new columns > > added. Maybe we can leverage set_pathtarget_cost_width for that. > > I'm not really sure we really need to make the estimates accurate, > because 1) the resulting EPQ plan is used only for rechecks, so the > estimates would not be that important IMO, and 2) in fact, we don't > adjust the estimates of a given EPQ plan in postgresGetForeignPlan() > even when replacing the plan's tlist and/or removing local conditions > from the plan. Is it worth expending the cycles here? 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? 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