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.
I don't have a good idea for this, so would an approach using an local
join execution plan be the good way to go?
Best regards,
Etsuro Fujita
