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

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:

Reply via email to