On Thu, Jan 14, 2016 at 9:31 AM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp>

> 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

Reply via email to