Re: Foreign join pushdown vs EvalPlanQual

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 <robertmhaas@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
bigft1JOIN 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