> On 2015/11/13 13:44, Kyotaro HORIGUCHI wrote: > > I wrote: > >>> What I think is, I > >>> see zero evidence that there is a good use-case for an FDW to do > >>> something other than doing an ExecProcNode in the callback routine, as I > >>> said below, so I don't see the need to add such a routine while that > >>> would cause maybe not a large, but not a little burden for writing such > >>> a routine on FDW authors. > > KaiGai-san wrote: > >> It is quite natural because we cannot predicate what kind of extension > >> is implemented on FDW interface. You might know the initial version of > >> PG-Strom is implemented on FDW (about 4 years before...). If I would > >> continue to stick FDW, it became a FDW driver with own join engine. > > >> From the standpoint of interface design, if we would not admit flexibility > >> of implementation unless community don't see a working example, a > >> reasonable > >> tactics *for extension author* is to follow the interface restriction even > >> if it is not best approach from his standpoint. > >> It does not mean the approach by majority is also best for the minority. > >> It just requires the minority a compromise. > > > Or try to open the way to introduce the feature he/she wants. > > I think the biggest difference between KaiGai-san's patch and mine is > that KaiGai-san's patch introduces a callback routine to allow an FDW > author not only to execute a secondary plan but to do something else, > instead of executing the plan, if he/she wants to do so. His approach > would provide the flexibility, but IMHO I think major FDWs that would be > implementing join pushdown, such as postgres_fdw, wouldn't be utilizing > the flexibility; probably, they would be just executing the secondary > plan in the routine. > Yes, my approach never deny.
> Furthermore, since that for executing the plan, > his approach would require that an FDW author has to add code not only > for creating the plan but for initializing > Pick up a plan from fdw_plans, then call ExecInitNode() > executing > Pick up a plan-state from fdw_ps then call ExecProcNode() > ending it to > Also, call ExecEndNode() towards the plan-state. > his/her FDW by itself while in my approach, he/she only has to add code > for the plan creation, his approach would impose a more development > burden on such major FDWs' authors than mine. > It looks to me the more development burden is additional three lines. Both of our approaches commonly needs to construct alternative local plan, likely unparametalized nest-loop, on planner phase, it shall be supported by a utility function in the core background. So, one more additional line will be eventually needed. > I think the flexibility > would be a good thing, but I also think it's important not to burden FDW > authors. Maybe I'm missing something, though. > The actual pain is people cannot design/implement their module as they want. I've repeatedly pointed out FDW driver can have own join implementation and people potentially want to use own logic than local plan. At least, if PG-Strom would still run on FDW, I *want* to reuse its CPU-fallback routine instead of the alternative sub-plan. Could you introduce us why above sequence (a few additional lines) are unacceptable burden and can justify to eliminate flexibility for minorities? If you can implement the "common part" for majority, we can implement same stuff as utility functions can be called from the callbacks. My questions are: * How much lines do you expect for the additional burden? * Why does it justify to eliminate flexibility of the interface? * Why cannot we implement the common part as utility routines that can be called from the callback? Please don't hesitate to point out flaw of my proposition, if you noticed something significant we have never noticed. However, at this moment, it does not seems to me your concern is something significant. 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
