Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)

> On Wed, Mar 25, 2015 at 3:14 PM, Shigeru HANADA <shigeru(dot)hanada(at)gmail(dot)com> wrote:
> 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).
>
In this case, GetForeignJoinPaths() will take root, joinrel, rel1, rel2,
sjinfo and restrictlist.
It is not too simple, but not complicated signature.

Even if we reconstruct rel1 and rel2 using sjinfo, we also need to compute
restrictlist using build_joinrel_restrictlist() again. It is a static function
in relnode.c. So, I don't think either of them has definitive advantage from
the standpoint of simplicity.

Thanks,
--
NEC OSS Promotion Center / PG-Strom Project
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>