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

  1. postgres_fdw: Avoid 'variable not found in subplan target list' error.