Re: Foreign join pushdown vs EvalPlanQual

> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Etsuro Fujita
> Sent: Thursday, October 08, 2015 7:56 PM
> To: Kyotaro HORIGUCHI; robertmhaas(at)gmail(dot)com
> Cc: Kaigai Kouhei(海外 浩平); pgsql-hackers(at)postgresql(dot)org;
> shigeru(dot)hanada(at)gmail(dot)com
> Subject: Re: [HACKERS] Foreign join pushdown vs EvalPlanQual
>
> On 2015/10/07 15:39, Etsuro Fujita wrote:
> > On 2015/10/07 15:06, Kyotaro HORIGUCHI wrote:
> >> At Wed, 7 Oct 2015 00:24:57 -0400, Robert Haas <robertmhaas(at)gmail(dot)com>
> >> wrote
> >>> I think it rather requires *replacing* two resjunk columns by one new
> >>> one. The whole-row references for the individual foreign tables are
> >>> only there to support EvalPlanQual; if we instead have a column to
> >>> populate the foreign scan's slot directly, then we can use that column
> >>> for that purpose directly and there's no remaining use for the
> >>> whole-row vars on the baserels.
>
> >> It is what I had in mind.
>
> > OK I'll investigate this further.
>
> I noticed that the approach using a column to populate the foreign
> scan's slot directly wouldn't work well in some cases. For example,
> consider:
>
> SELECT * FROM verysmall v LEFT JOIN (bigft1 JOIN bigft2 ON bigft1.x =
> bigft2.x) ON v.q = bigft1.q AND v.r = bigft2.r FOR UPDATE OF v;
>
> The best plan is presumably something like this as you said before:
>
> LockRows
> -> Nested Loop
> -> Seq Scan on verysmall v
> -> Foreign Scan on bigft1 and bigft2
> Remote SQL: SELECT * FROM bigft1 JOIN bigft2 ON bigft1.x =
> bigft2.x AND bigft1.q = $1 AND bigft2.r = $2
>
> Consider the EvalPlanQual testing to see if the updated version of a
> tuple in v satisfies the query. If we use the column in the testing, we
> would get the wrong results in some cases.
>
In this case, does ForeignScan have to be reset prior to ExecProcNode()?
Once ExecReScanForeignScan() gets called by ExecNestLoop(), it marks EPQ
slot is invalid. So, more or less, ForeignScan needs to kick the remote
join again based on the new parameter come from the latest verysmall tuple.
Please correct me, if I don't understand correctly.
In case of unparametalized ForeignScan case, the cached join-tuple work
well because it is independent from verysmall.

Once again, if FDW driver is responsible to construct join-tuple from
the base relation's tuple cached in EPQ slot, this case don't need to
kick remote query again, because all the materials to construct join-
tuple are already held locally. Right?

Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>