Re: Foreign join pushdown vs EvalPlanQual - Mailing list 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>