> -----Original Message----- > From: Etsuro Fujita [mailto:fujita.ets...@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.ets...@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 <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
