> -----Original Message----- > From: Etsuro Fujita [mailto:fujita.ets...@lab.ntt.co.jp] > Sent: Wednesday, August 26, 2015 5:38 PM > To: Kaigai Kouhei(海外 浩平); Robert Haas > Cc: PostgreSQL-development; 花田茂 > Subject: Re: [HACKERS] Foreign join pushdown vs EvalPlanQual > > 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. > I'm not interested in advantage / disadvantage of individual FDW driver's implementation. It is matter of FDW drivers, not a matter of core PostgreSQL.
The only and significant point I repeatedly emphasized is, it is developer's choice thus it is important to provide options for developers. If they want, FDW developer can follow the manner of alternative plan execution for EPQ rechecks. I never deny your idea, but should be one of the options we can take. Thanks, -- NEC Business Creation Division / PG-Strom Project KaiGai Kohei <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
