Re: Foreign join pushdown vs EvalPlanQual

> On 2015/08/26 18:01, Kouhei Kaigai wrote:
> >>> 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.
>
> Maybe my explanation was not accurate, but I just want to know use
> cases, to understand the need to provide the flexiblity.
>
Let's assume the following situation:

Someone wants to implement FPGA acceleration feature on top of FDW.
(You may know the earliest PG-Strom was built on FDW interface)
It enables to run SQL join workloads on FPGA device, but has equivalent
fallback routines to be executed if FPGA returned an error.
On EPQ check case, it is quite natural that he wants to re-use this
fallback routine to validate EPQ tuple. Alternative plan may consume
additional (at least not zero) memory and other system resource.

As I have said repeatedly, it is software design decision by the author
of extension. Even if it consumes 100 times larger memory and 1000 times
slower, it is his decision and responsibility.
Why he has to be forced to use a particular logic despite his intension?

> > 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.
>
> I don't object about your idea either, but I have a concern about that;
> it looks like that the more flexiblity we provide, the more the FDWs
> implementing their own EPQ would be subject to an internal change in the
> core.
>
We never guarantee interface compatibility across major versions. All we
can say is 'best efforts'. So, it is always role of extension owner, as
long as he continue to maintain his module.

Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>