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

On Wed, Aug 31, 2022 at 6:27 PM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
> 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?

I agree with you on that point. I’ll update the patch as such in the
next version.

Best regards,
Etsuro Fujita