On 2016/02/04 21:42, Ashutosh Bapat wrote:
> * Is it safe to replace outerjoinpath with its fdw_outerpath the
> following way? I think that if the join relation represented by
> outerjoinpath has local conditions that can't be executed remotely,
> we have to keep outerjoinpath in the path tree; we will otherwise
> fail to execute the local conditions. No?
>
> + /*
> + * If either inner or outer path is a
> ForeignPath corresponding to
> + * a pushed down join, replace it with the
> fdw_outerpath, so that we
> + * maintain path for EPQ checks built
> entirely of local join
> + * strategies.
> + */
> + if (IsA(joinpath->outerjoinpath, ForeignPath))
> + {
> + ForeignPath *foreign_path;
> + foreign_path = (ForeignPath
> *)joinpath->outerjoinpath;
> + if
> (foreign_path->path.parent->reloptkind == RELOPT_JOINREL)
> + joinpath->outerjoinpath =
> foreign_path->fdw_outerpath;
> + }
> all the conditions (local and remote) should be part of fdw_outerpath as
> well, since that's the alternate local path, which should produce (when
> converted to the plan) the same result as the foreign path.
> fdw_outerpath should be a local path set when paths for
> outerjoinpath->parent was being created. Am I missing something?
I assumed by mistake that only the remote conditions were evaluated in a
plan created from each fdw_outerpath. Sorry for that. I think that is
a good idea!
Btw, IIUC, I think the patch fails to adjust the targetlist of the top
plan created that way, to output the fdw_scan_tlist, as discussed in [1]
(ie, I think the attached patch is needed, which is created on top of
your patch pg_fdw_join_v8.patch).
Best regards,
Etsuro Fujita
[1]
http://www.postgresql.org/message-id/CA+TgmobA4MSKgquicgt5CkbpQJ-TmpqEfHt_wy49ndwa91Wkpw@mail.gmail.com