> -----Original Message----- > From: Etsuro Fujita [mailto:fujita.ets...@lab.ntt.co.jp] > Sent: Monday, October 19, 2015 8:52 PM > To: Kaigai Kouhei(海外 浩平); Kyotaro HORIGUCHI > Cc: pgsql-hackers@postgresql.org; shigeru.han...@gmail.com; > robertmh...@gmail.com > Subject: Re: [HACKERS] Foreign join pushdown vs EvalPlanQual > > I wrote: > >> As Robert mentioned in [1], I think that if we're inside EPQ, > >> pushed-down quals and/or pushed-down joins should be locally rechecked > >> in the same way as other cases such as IndexRecheck. So, I'll propose > >> the updated version of the patch. > > On 2015/10/16 18:48, Kouhei Kaigai wrote: > > You have never answered my question for two months. > > > > I never deny to execute the pushed-down qualifiers locally. > > It is likely the best tactics in most cases. > > But, why you try to enforce all the people a particular manner? > > > > Here are various kind of FDW drivers. How do you guarantee it is > > the best solution for all the people? It is basically impossible. > > (Please google "Probatio diabolica") > > > > You try to add two special purpose fields in ForeignScan; > > fdw_recheck_plan and fdw_recheck_quals. > > It requires FDW drivers to have pushed-down qualifier in a particular > > data format, and also requires FDW drivers to process EPQ recheck by > > alternative local plan, even if a part of FDW drivers can process > > these jobs by its own implementation better. > > > > I've repeatedly pointed out this issue, but never get reasonable > > answer from you. > > > > Again, I also admit alternative plan may be reasonable tactics for > > most of FDW drivers. However, only FDW author can "decide" it is > > the best tactics to handle the task for their module, not us. > > > > I don't think it is a good interface design to enforce people to > > follow a particular implementation manner. It should be discretion > > of the extension. > > I think that if you think so, you should give at least one concrete > example for that. Ideally accompanied by a demo of how that works well. > I previously showed an example situation: http://www.postgresql.org/message-id/9a28c8860f777e439aa12e8aea7694f801138...@bpxm15gp.gisp.nec.co.jp
Then, your response was below: | Thanks for the answer, but I'm not still convinced. | I think the EPQ testing shown in that use-case would probably not | efficient, compared to the core's. What I'm repeatedly talking about is flexibility of the interface, not efficiently. If core backend provide a good enough EPQ recheck routine, extension can call it but decision by its author. Why do you want to prohibit extension to choose its implementation? Also, I introduced the case of PG-Strom in the face-to-face meeting with you. PG-Strom has self CPU-fallback routine to rescue GPU errors. thus, I prefer to reuse this routine for EPQ rechecks, rather than adding alternative local plan support here. 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
