Re: Foreign join pushdown vs EvalPlanQual
От | Kouhei Kaigai |
---|---|
Тема | Re: Foreign join pushdown vs EvalPlanQual |
Дата | |
Msg-id | 9A28C8860F777E439AA12E8AEA7694F80115A596@BPXM15GP.gisp.nec.co.jp обсуждение исходный текст |
Ответ на | Re: Foreign join pushdown vs EvalPlanQual (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>) |
Список | pgsql-hackers |
> -----Original Message----- > From: Etsuro Fujita [mailto:fujita.etsuro@lab.ntt.co.jp] > Sent: Monday, October 19, 2015 8:52 PM > To: Kaigai Kouhei(海外 浩平); Kyotaro HORIGUCHI > Cc: pgsql-hackers@postgresql.org; shigeru.hanada@gmail.com; > robertmhaas@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/9A28C8860F777E439AA12E8AEA7694F801138B6F@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 <kaigai@ak.jp.nec.com>
В списке pgsql-hackers по дате отправления:
Следующее
От: Tomas VondraДата:
Сообщение: Re: fs issues on software raid0 (PG_VERSION does not contain valid data)