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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
