On 2015/10/07 15:39, Etsuro Fujita wrote:
On 2015/10/07 15:06, Kyotaro HORIGUCHI wrote:
At Wed, 7 Oct 2015 00:24:57 -0400, Robert Haas <robertmh...@gmail.com>
wrote
I think it rather requires *replacing* two resjunk columns by one new
one. The whole-row references for the individual foreign tables are
only there to support EvalPlanQual; if we instead have a column to
populate the foreign scan's slot directly, then we can use that column
for that purpose directly and there's no remaining use for the
whole-row vars on the baserels.
It is what I had in mind.
OK I'll investigate this further.
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;
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.
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
