> > Also, I don't want to stick on the assumption that relations involved in
> > remote join are all managed by same foreign-server no longer.
> > The following two ideas introduce possible enhancement of remote join
> > feature that involved local relations; replicated table or transformed
> > to VALUES() clause.
> >
> >
> http://www.postgresql.org/message-id/CA+Tgmoai_VUF5h6qVLNLU+FKp0aeBCbnnMT3SC
> vL-HvOpBR=Xw@mail.gmail.com
> >
> http://www.postgresql.org/message-id/9A28C8860F777E439AA12E8AEA7694F8010F20A
> D@BPXM15GP.gisp.nec.co.jp
>
> Interesting!
>
> > I think add_paths_to_joinrel() is the best location for foreign-join,
> > not only custom-join. Relocation to standard_join_search() has larger
> > disadvantage than its advantage.
>
> I agree with you that it's important to ensure the expandability, and my
> question is, is it possible that the API call from standard_join_search
> also realize those idea if FDWs can get the join information through the
> root or something like that?
>
I don't deny its possibility, even though I once gave up to implement to
reproduce join information - which relations and other ones are joined in
this level - using PlannerInfo and RelOptInfo.
However, we need to pay attention on advantages towards the alternatives.
Hooks on add_paths_to_joinrel() enables to implement identical stuff, with
less complicated logic to reproduce left / right relations from RelOptInfo
of the joinrel. (Note that RelOptInfo->fdw_private enables to avoid path-
construction multiple times.)
I'm uncertain why this API change is necessary to fix up the problem
around EvalPlanQual.
Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>
