Re: Foreign join pushdown vs EvalPlanQual

On 2015/10/09 15:04, Kyotaro HORIGUCHI wrote:
> At Fri, 9 Oct 2015 12:00:30 +0900, Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote in <56172DCE(dot)7080604(at)lab(dot)ntt(dot)co(dot)jp>
>> On 2015/10/08 19:55, Etsuro Fujita wrote:
>>> 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;

>> Oops, I should have written "JOIN", not "LEFT JOIN".

>>> 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.

>> More precisely, we would get the wrong result when the value of v.q or
>> v.r in the updated version has changed.

> What do you think the right behavior?

IIUC, I think that the foreign scan's slot should be set empty, that the
join should fail, and that the updated version of the tuple in v should
be ignored in that scenario since that for the updated version of the
tuple in v, the tuples obtained from those two foreign tables wouldn't
satisfy the remote query. But if populating the foreign scan's slot
from that column, then the join would success and the updated version of
the tuple in v would be returned wrongly, I think.

Best regards,
Etsuro Fujita