Re: Foreign join pushdown vs EvalPlanQual - Mailing list pgsql-hackers

> -----Original Message-----
> From: Kyotaro HORIGUCHI [mailto:horiguchi.kyotaro@lab.ntt.co.jp]
> Sent: Thursday, November 05, 2015 10:02 AM
> To: fujita.etsuro@lab.ntt.co.jp
> Cc: Kaigai Kouhei(海外 浩平); robertmhaas@gmail.com; tgl@sss.pgh.pa.us;
> pgsql-hackers@postgresql.org; shigeru.hanada@gmail.com
> Subject: Re: [HACKERS] Foreign join pushdown vs EvalPlanQual
>
> Hi, I've caught up again.
>
> > OK, so if we all agree that the joined-tuple optimization is just an
> > option for the case where all the component tables use ROW_MARK_COPY,
> > I'd propose to leave that for 9.6.
>
> I still think that ExecScan is called under EPQ recheck without
> EQP tuple for the *scan*.
>
> The ForeignScan can be generated for a join and underlying
> foreign scans and such execution node returns what the core
> deesn't expect for any scan node. This is what I think is the
> root cause of this problem.
>
> So, as the third way, I propose to resurrect the abandoned
> ForeinJoinState seems to be for the unearthed requirements. FDW
> returns ForeignJoinPath, not ForeignScanPath then finally it
> becomes ForeignJoinState, which is handeled as a join node with
> no doubt.
>
> What do you think about this?
>
Apart from EPQ issues, it is fundamentally impossible to reflect
the remote join tree on local side, because remote server runs
the partial join in their best or arbitrary way.
If this ForeignJoinState has just a compatible join sub-tree, what
is the difference from the alternative local join sub-plan?

Even if we have another node, the roles of FDW driver is unchanged.
It eventually needs to do them:1. Recheck scan-qualifier of base foreign table2. Recheck join-clause of remote joins3.
Reconstructa joined tuple 


I try to estimate your intention...
You say that ForeignScan with scanrelid==0 is not a scan actually,
so it is problematic to call ExecScan on ExecForeignScan always.
Thus, individual ForeignJoin shall be defined.
Right?


In case of scanrelid==0, it performs like a scan on pseudo relation
that has record type defined by fdw_scan_tlist. The rows generated
with this node are consists of rows in underlying base relations.
A significant point is, FDW driver is responsible to generate the
rows according to the fdw_scan_tlist. Once FDW driver generates rows,
ExecScan() runs remaining tasks - execution of host clauses (although
it is not easy to image remote join includes host clause has cheaper
cost than others) and projection.

One thing I can agree is, ForeignScan is enforced to use ExecScan,
thus some FDW driver may concern about this hard-wired logic.
If we try to make ForeignScan unbound from the ExecScan, I like to
suggest to revise ExecForeignScan, just invoke a callback; then
FDW driver can choose whether ExecScan is best or not.

Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>