Re: FDW join pushdown and scanclauses - Mailing list pgsql-hackers

From Etsuro Fujita
Subject Re: FDW join pushdown and scanclauses
Date
Msg-id 56971DAC.7010404@lab.ntt.co.jp
Whole thread Raw
In response to FDW join pushdown and scanclauses  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Responses Re: FDW join pushdown and scanclauses  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
List pgsql-hackers
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.

> 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.

Best regards,
Etsuro Fujita





pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: Python 3.x versus PG 9.1 branch
Next
From: Michael Paquier
Date:
Subject: Re: Python 3.x versus PG 9.1 branch