> -----Original Message-----
> From: Etsuro Fujita [mailto:fujita.etsuro@lab.ntt.co.jp]
> Sent: Tuesday, October 20, 2015 1:11 PM
> To: Robert Haas
> Cc: Tom Lane; Kaigai Kouhei(海外 浩平); Kyotaro HORIGUCHI;
> pgsql-hackers@postgresql.org; Shigeru Hanada
> Subject: Re: [HACKERS] Foreign join pushdown vs EvalPlanQual
>
> On 2015/10/20 5:34, Robert Haas wrote:
> > On Mon, Oct 19, 2015 at 3:45 AM, Etsuro Fujita
> > <fujita.etsuro@lab.ntt.co.jp> wrote:
> >> As Tom mentioned, just recomputing the original join tuple is not good
> >> enough. We would need to rejoin the test tuples for the baserels even if
> >> ROW_MARK_COPY is in use. Consider:
> >>
> >> A=# BEGIN;
> >> A=# UPDATE t SET a = a + 1 WHERE b = 1;
> >> B=# SELECT * from t, ft1, ft2
> >> WHERE t.a = ft1.a AND t.b = ft2.b AND ft1.c = ft2.c FOR UPDATE;
> >> A=# COMMIT;
> >>
> >> where the plan for the SELECT FOR UPDATE is
> >>
> >> LockRows
> >> -> Nested Loop
> >> -> Seq Scan on t
> >> -> Foreign Scan on <ft1, ft2>
> >> Remote SQL: SELECT * FROM ft1 JOIN ft2 WHERE ft1.c = ft2.c AND ft1.a
> >> = $1 AND ft2.b = $2
> >>
> >> If an EPQ recheck is invoked by the A's UPDATE, just recomputing the
> >> original join tuple from the whole-row image that you proposed would output
> >> an incorrect result in the EQP recheck since the value a in the updated
> >> version of a to-be-joined tuple in t would no longer match the value ft1.a
> >> extracted from the whole-row image if the A's UPDATE has committed
> >> successfully. So I think we would need to rejoin the tuples populated from
> >> the whole-row images for the baserels ft1 and ft2, by executing the
> >> secondary plan with the new parameter values for a and b.
>
> > No. You just need to populate fdw_recheck_quals correctly, same as
> > for the scan case.
>
> Yeah, I think we can probably do that for the case where a pushed-down
> join clause is an inner-join one, but I'm not sure that we can do that
> for the case where that clause is an outer-join one. Maybe I'm missing
> something, though.
>
Please check my message yesterday. The non-nullable side of outer-join is
always visible regardless of the join-clause pushed down, as long as it
satisfies the scan-quals pushed-down.
Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>
