> > 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=x...@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 <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
