Hello, At Fri, 2 Oct 2015 12:51:42 +0900, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote in <560dff4e.2000...@lab.ntt.co.jp> > On 2015/10/02 9:50, Kyotaro HORIGUCHI wrote:
Most of the citation are of Kiagai-san's mentions:) > >> 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 ... Agreed, except for the necessity of RefetchForeignJoinRow. > >> * 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. One coarse idea is that adding root->rowMarks for the "foreign join" paths (then removing rowMarks for underlying scans later if the foreign join wins). Somehow propagating it to epqstate->arowMarks, EvalPlanQualFetchRowMarks will stores needed tuple into eqptuples. This is which Kaigai-san criticized as 'makes things too complex'.:) But I'm awkward to break the assumption of ExecScanFetch. > > 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. Sorry, please ignore "possibly modified". regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
