On 2015/10/02 9:50, Kyotaro HORIGUCHI wrote:
As long as FDW author can choose their best way to produce a joined
tuple, it may be worth to investigate.
My comments are:
* ForeignRecheck is the best location to call RefetchForeignJoinRow
when scanrelid==0, not ExecScanFetch. Why you try to add special
case for FDW in the common routine.
In my understanding, the job that ExecScanRecheckMtd should do is to
check if the test tuple *already stored* in the plan node's scan slot
meets the access-method conditions, in general. So, ISTM that it'd be
somewhat odd to replace RefetchForeignJoinRow within ForeignRecheck, to
store the remote join tuple in the slot. Also, RefetchForeignRow is
called from the common routines ExecLockRows/EvalPlanQualFetchRowMarks ...
* It is FDW's choice where the remote join tuple is kept, even though
most of FDW will keep it on the private field of ForeignScanState.
I see.
To make it possible that the FDW doesn't have to do anything for cases
where the FDW doesn't do any late row locking, however, I think it'd be
more promising to use the remote join tuple stored in the scan slot of
the corresponding ForeignScanState node in the parent's planstate tree.
I haven't had a good idea for that yet, though.
EvalPlanQualFetchRowMarks fetches the possiblly
modified row then EvalPlanQualNext does recheck for the new
row.
Really? EvalPlanQualFetchRowMarks fetches the tuples for any non-locked
relations, so I think that that function should fetch the same version
previously obtained for each such relation successfully.
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
