2015/03/25 12:59、Kouhei Kaigai <kai...@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 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. Though I’m not sure that it also fits custom join provider’s requirements. — Shigeru HANADA -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
