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

2015/03/25 12:59、Kouhei Kaigai <kaigai@ak.jp.nec.com> のメール：

>>> At this moment, I'm not 100% certain about its logic. Especially, I didn't
>>> test SEMI- and ANTI- join cases yet.
>>> However, time is money - I want people to check overall design first, rather
>>> than detailed debugging. Please tell me if I misunderstood the logic to break
>>> down join relations.
>>
>> With applying your patch, regression tests of “updatable view” failed.
>> regression.diff contains some errors like this:
>> ! ERROR:  could not find RelOptInfo for given relids
>>
>> Could you check that?
>>
> It is a bug around the logic to find out two RelOptInfo that can construct
> another RelOptInfo of joinrel.
> Even though I'm now working to correct the logic, it is not obvious to
> identify two relids that satisfy joinrel->relids.
> (Yep, law of entropy enhancement…)

IIUC, this problem is in only non-INNER JOINs because we can treat relations joined with only INNER JOIN in arbitrary
order. But supporting OUTER JOINs would be necessary even for the first cut. 

> On the other hands, we may have a solution that does not need a complicated
> reconstruction process. The original concern was, FDW driver may add paths
> that will replace entire join subtree by foreign-scan on remote join multiple
> times, repeatedly, but these paths shall be identical.
>
> If we put a hook for FDW/CSP on bottom of build_join_rel(), we may be able
> to solve the problem more straight-forward and simply way.
> Because build_join_rel() finds a cache on root->join_rel_hash then returns
> immediately if required joinrelids already has its RelOptInfo, bottom of
> this function never called twice on a particular set of joinrelids.
> Once FDW/CSP constructs a path that replaces entire join subtree towards
> the joinrel just after construction, it shall be kept until cheaper built-in
> paths are added (if exists).
>
> This idea has one other positive side-effect. We expect remote-join is cheaper
> than local join with two remote scan in most cases. Once a much cheaper path
> is added prior to local join consideration, add_path_precheck() breaks path
> consideration earlier.
>
> Please comment on.

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. 

Though I’m not sure that it also fits custom join provider’s requirements.

—
Shigeru HANADA