On Thu, Jan 14, 2016 at 9:31 AM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote:
> On 2016/01/08 22:05, Ashutosh Bapat wrote: > >> In add_paths_to_joinrel(), the FDW specific hook GetForeignJoinPaths() >> is called. This hook if implemented should add ForeignPaths for pushed >> down joins. create_plan_recurse() calls create_scan_plan() on seeing >> these paths. >> > > create_scan_plan() generates a list of clauses to be applied on scan >> from rel->baserestrictinfo and parameterization clauses. This list is >> passed to create_*scan_plan routine as scanclauses. This code is very >> specific for single relations scans. Now that we are using >> create_scan_plan() for creating plan for join relations, it needs some >> changes so that quals relevant to a join can be passed to >> create_foreignscan_plan(). >> > > Do we really need that? The relevant join quals are passed to > GetForeignJoinPaths as extra->restrictlist, so I think we can get those > quals during GetForeignPlan, by looking at the selected ForeignPath that is > passed to that function as a parameter. > Right! You are suggesting that an FDW should just ignore scan_clauses for join relation and manage those by itself. That looks fine. > > A related problem is in >> create_foreignscan_plan(), which sets ForeignScan::fsSystemCol if a >> system column is being used in the targetlist or quals. Right now it >> only checks rel->baserestrictinfo, which is NULL for a joinrel. Thus in >> case a system column appears in the joinclauses it will not be considered. >> > > IIUC, we assume that such system columns are assumed to be contained in > fdw_scan_tlist in the joinrel case. > >From another mail thread [1] that you have started, I understood that fsSystemCol should not be set for a join relation, so the bug doesn't exist. [1] http://www.postgresql.org/message-id/559f9323.4080...@lab.ntt.co.jp Thanks for your inputs. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
