From: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: FDW join pushdown and scanclauses |
Date: | 2016-01-14 04:01:48 |
Message-ID: | 56971DAC.7010404@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2016-01-14 04:27:33 | Re: Python 3.x versus PG 9.1 branch |
Previous Message | Noah Misch | 2016-01-14 03:37:04 | Re: Python 3.x versus PG 9.1 branch |