On 2015/08/26 17:05, Kouhei Kaigai wrote:
>> On 2015/08/26 16:07, Kouhei Kaigai wrote:
>>> 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?
> TupleTableSlot *
> ExecForeignScan(ForeignScanState *node)
> {
> + EState *estate = node->ss.ps.state;
> +
> + if (estate->es_epqTuple != NULL)
> + {
> + /*
> + * We are inside an EvalPlanQual recheck. If foreign join, get next
> + * tuple from subplan.
> + */
> + Index scanrelid = ((Scan *) node->ss.ps.plan)->scanrelid;
> +
> + if (scanrelid == 0)
> + {
> + PlanState *outerPlan = outerPlanState(node);
> +
> + return ExecProcNode(outerPlan);
> + }
> + }
> 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.
As I said below, EPQ testing is only execute a subplan for a *single*
set of component test tuples, so I think the performance gain by its own
EPQ testing implemented by an FDW would be probably negligible in
practice. No?
>>> 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.
No, I just want to know the need or advantage for that specifically.
Best regards,
Etsuro Fujita
