Re: Foreign join pushdown vs EvalPlanQual - Mailing list pgsql-hackers

> > > > Who can provide a projection to generate joined tuple?
> > > > It is a job of individual plan-state-node to be walked on during
> > > > EvalPlanQualNext().
> > >
> > > EvalPlanQualNext simply does recheck tuples stored in epqTuples,
> > > which are designed to be provided by EvalPlanQualFetchRowMarks.
> > >
> > > I think that that premise shouldn't be broken for convenience...
> > >
> > Do I see something different or understand incorrectly?
> > EvalPlanQualNext() walks down entire subtree of the Lock node.
> > (epqstate->planstate is entire subplan of Lock node.)
> >
> >   TupleTableSlot *
> >   EvalPlanQualNext(EPQState *epqstate)
> >   {
> >       MemoryContext oldcontext;
> >       TupleTableSlot *slot;
> >
> >       oldcontext = MemoryContextSwitchTo(epqstate->estate->es_query_cxt);
> >       slot = ExecProcNode(epqstate->planstate);
> >       MemoryContextSwitchTo(oldcontext);
> >
> >       return slot;
> >   }
> >
> > If and when relations joins are kept in the sub-plan, ExecProcNode()
> > processes the projection by join, doesn't it?
>
> Yes, but it is needed to prepare alternative plan to do such
> projection.
>
No matter. The custom-scan node is a good reference to have underlying
plan nodes that can be kicked by extension.
If we adopt same semantics, these alternative plan shall not be kicked
unless FDW driver does not want.

Also, I don't think it is difficult to construct an alternative join-
path using unparametalized nested-loop (note that all we need to do is
evaluation towards a most one tuples for each base relation).

If people felt it is really re-invention of the wheel, core backend can
provide a utility function to produce the alternative path.

Probably,
 Path * foreign_join_alternative_local_join_path(PlannerInfo *root,                                          RelOptInfo
*joinrel)

can generate what we need.

> > Why projection by join is not a part of EvalPlanQualNext()?
> > It is the core of its job. Unless projection by join, upper node cannot
> > recheck the tuple come from child nodes.
>
> What I'm uneasy on is the foreign join introduced the difference
> in behavior between ordinary fetching and epq fetching. It is
> quite natural having joined whole row but is seems hard to get.
>
hard to get, and easy to construct on the fly.

> Another reason is that ExecScanFetch with scanrelid == 0 on EPQ
> is FDW/CS specific feature and looks to be a kind of hack. (Even
> if it would be one of many)
>
It means these are kind of exceptional ones, thus it is reasonable
to avoid fundamental changes in RowLock mechanism, isn't it?

Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>