Hello, I had a look on this.
At Wed, 25 Mar 2015 03:59:28 +0000, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote in
<9A28C8860F777E439AA12E8AEA7694F8010C6819@BPXM15GP.gisp.nec.co.jp>
> > > 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.
It is caused by split (or multilevel) joinlist. Setting
join_collapse_limit to 10 makes the query to go well.
I suppose that get_joinrel_broken_down should give up returning
result when given joinrel spans over multiple join subproblems,
becuase they cannot be merged by FDW anyway even if they
comformed the basic requirements for merging.
> 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...)
>
> 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.
+1 as a whole.
regards,
--
堀口恭太郎
日本電信電話株式会社 NTTオープンソースソフトウェアセンタ
Phone: 03-5860-5115 / Fax: 03-5463-5490