> 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 <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
