Re: Foreign join pushdown vs EvalPlanQual - Mailing list pgsql-hackers

From Etsuro Fujita
Subject Re: Foreign join pushdown vs EvalPlanQual
Date
Msg-id 56495ABE.6060805@lab.ntt.co.jp
Whole thread Raw
In response to Re: Foreign join pushdown vs EvalPlanQual  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: Foreign join pushdown vs EvalPlanQual  (Kouhei Kaigai <kaigai@ak.jp.nec.com>)
List 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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: proposal: PL/Pythonu - function ereport
Next
From: Pavel Stehule
Date:
Subject: Re: proposal: PL/Pythonu - function ereport