Re: Foreign join pushdown vs EvalPlanQual

Hello,

At Fri, 2 Oct 2015 12:51:42 +0900, Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote in <560DFF4E(dot)2000001(at)lab(dot)ntt(dot)co(dot)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