> On 2015/08/26 16:07, Kouhei Kaigai wrote:
> I wrote:
> >> Maybe I'm missing something, but why do we need such a flexiblity for
> >> the columnar-stores?
>
> > Even if we enforce them a new interface specification comfortable to RDBMS,
> > we cannot guarantee it is also comfortable to other type of FDW drivers.
>
> Specifically, what kind of points about the patch are specific to RDBMS?
>
*** 88,93 **** ForeignRecheck(ForeignScanState *node, TupleTableSlot *slot) --- 99,122 ---- TupleTableSlot *
ExecForeignScan(ForeignScanState*node) { + EState *estate = node->ss.ps.state; + + if
(estate->es_epqTuple!= NULL) + { + /* + * We are inside an EvalPlanQual recheck. If foreign join,
getnext + * tuple from subplan. + */ + Index scanrelid = ((Scan *)
node->ss.ps.plan)->scanrelid;+ + if (scanrelid == 0) + { + PlanState *outerPlan =
outerPlanState(node);+ + return ExecProcNode(outerPlan); + } + } + return
ExecScan((ScanState*) node, (ExecScanAccessMtd) ForeignNext,
(ExecScanRecheckMtd)ForeignRecheck);
It might not be specific to RDBMS, however, we cannot guarantee all the FDW are
comfortable to run the alternative plan node on EPQ recheck.
This design does not allow FDW drivers to implement own EPQ recheck, possibly
more efficient than built-in logic.
I never deny to run the alternative plan to implement EPQ recheck, according
to the decision by FDW driver, however, it is unacceptable pain to enforce all
the FDW driver to use alternative plan as a solution of EPQ check.
> > If module-X wants to implement the EPQ fallback routine by itself, without
> > alternative plan, too rich interface design prevents what module-X really
> > wants to do.
>
> Sorry, I fail to see the need or advantage for module-X to do so, in
> practice because I think EPQ testing is only execute a subplan for a
> *single* set of component test tuples. Maybe I'm missing something, though.
>
You may think execution of alternative plan is the best way for EPQ rechecks,
however, other folks may think their own implementation is the best for EPQ
rechecks. I never argue which approach is better.
What I point out is freedom/flexibility of implementation choice.
Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>
