Re: foreign join error "variable not found in subplan target list"

On Tue, Aug 30, 2022 at 3:50 PM Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>
wrote:

> On Mon, Aug 29, 2022 at 6:46 PM Richard Guo <guofenglinux(at)gmail(dot)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