> > Or bottom of make_join_rel(). IMO build_join_rel() is responsible for just
> building (or searching from a list) a RelOptInfo for given relids. After that
> make_join_rel() calls add_paths_to_joinrel() with appropriate arguments per join
> type to generate actual Paths implements the join. make_join_rel() is called
> only once for particular relid combination, and there SpecialJoinInfo and
> restrictlist (conditions specified in JOIN-ON and WHERE), so it seems promising
> for FDW cases.
> >
> > I like that idea, but I think we will have complex hook signature, it won't
> remain as simple as hook (root, joinrel).
>
> Signature of the hook (or the FDW API handler) would be like this:
>
> typedef void (*GetForeignJoinPaths_function ) (PlannerInfo *root,
> RelOptInfo *joinrel,
> RelOptInfo *outerrel,
> RelOptInfo *innerrel,
> JoinType jointype,
> SpecialJoinInfo *sjinfo,
> List *restrictlist);
>
> This is very similar to add_paths_to_joinrel(), but lacks semifactors and
> extra_lateral_rels. semifactors can be obtained with
> compute_semi_anti_join_factors(), and extra_lateral_rels can be constructed
> from root->placeholder_list as add_paths_to_joinrel() does.
>
> From the viewpoint of postgres_fdw, jointype and restrictlist is necessary to
> generate SELECT statement, so it would require most work done in make_join_rel
> again if the signature was hook(root, joinrel). sjinfo will be necessary for
> supporting SEMI/ANTI joins, but currently it is not in the scope of postgres_fdw.
>
> I guess that other FDWs require at least jointype and restrictlist.
>
The attached patch adds GetForeignJoinPaths call on make_join_rel() only when
'joinrel' is actually built and both of child relations are managed by same
FDW driver, prior to any other built-in join paths.
I adjusted the hook definition a little bit, because jointype can be reproduced
using SpecialJoinInfo. Right?
Probably, it will solve the original concern towards multiple calls of FDW
handler in case when it tries to replace an entire join subtree with a foreign-
scan on the result of remote join query.
How about your opinion?
Thanks,
--
NEC OSS Promotion Center / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>
