Re: Foreign join pushdown vs EvalPlanQual
От | Etsuro Fujita |
---|---|
Тема | Re: Foreign join pushdown vs EvalPlanQual |
Дата | |
Msg-id | 56495ABE.6060805@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Foreign join pushdown vs EvalPlanQual (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Ответы |
Re: Foreign join pushdown vs EvalPlanQual
|
Список | pgsql-hackers |
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. 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/executing/ending it to 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. 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. Best regards, Etsuro Fujita
В списке pgsql-hackers по дате отправления: