2015/03/25 18:53、Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> のメール：
>
>
> On Wed, Mar 25, 2015 at 3:14 PM, Shigeru HANADA <shigeru.hanada@gmail.com> wrote:
>
> Or bottom of make_join_rel(). IMO build_join_rel() is responsible for just building (or searching from a list) a
RelOptInfofor given relids. After that make_join_rel() calls add_paths_to_joinrel() with appropriate arguments per
jointype 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
promisingfor 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
obtainedwith 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
requiremost work done in make_join_rel again if the signature was hook(root, joinrel). sjinfo will be necessary for
supportingSEMI/ANTI joins, but currently it is not in the scope of postgres_fdw.
I guess that other FDWs require at least jointype and restrictlist.
—
Shigeru HANADA