On 2015/10/14 12:07, Kouhei Kaigai wrote:
>> On 2015/10/07 15:39, 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;
>>
>> 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.
> In this case, does ForeignScan have to be reset prior to ExecProcNode()?
> Once ExecReScanForeignScan() gets called by ExecNestLoop(), it marks EPQ
> slot is invalid. So, more or less, ForeignScan needs to kick the remote
> join again based on the new parameter come from the latest verysmall tuple.
> Please correct me, if I don't understand correctly.
> In case of unparametalized ForeignScan case, the cached join-tuple work
> well because it is independent from verysmall.
>
> Once again, if FDW driver is responsible to construct join-tuple from
> the base relation's tuple cached in EPQ slot, this case don't need to
> kick remote query again, because all the materials to construct join-
> tuple are already held locally. Right?
Sorry, maybe I misunderstand your words, but we are talking here about
an approach using a whole-row var that would populate a join tuple that
is returned by an FDW and stored in the scan slot in the corresponding
ForeingScanState node in the parent state tree.
Best regards,
Etsuro Fujita
