Re: Foreign join pushdown vs EvalPlanQual

From: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, kaigai(at)ak(dot)jp(dot)nec(dot)com
Cc: robertmhaas(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org, shigeru(dot)hanada(at)gmail(dot)com
Subject: Re: Foreign join pushdown vs EvalPlanQual
Date: 2015-11-16 04:25:34
Message-ID: 56495ABE.6060805@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2015-11-16 04:29:58 Re: proposal: PL/Pythonu - function ereport
Previous Message Peter Eisentraut 2015-11-16 04:20:56 Re: proposal: PL/Pythonu - function ereport