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> |
Cc: | robertmhaas(at)gmail(dot)com, kaigai(at)ak(dot)jp(dot)nec(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-12 10:33:33 |
Message-ID: | 56446AFD.2050208@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Horiguchi-san,
On 2015/11/12 16:10, Kyotaro HORIGUCHI wrote:
>>> I really don't see why you're fighting on this point. Making this a
>>> generic feature will require only a few extra lines of code for FDW
>>> authors. If this were going to cause some great inconvenience for FDW
>>> authors, then I'd agree it isn't worth it. But I see zero evidence
>>> that this is actually the case.
>> Really? I think there would be not a little burden on an FDW author;
>> when postgres_fdw delegates to the subplan to the remote server, for
>> example, it would need to create a remote join query by looking at
>> tuples possibly fetched and stored in estate->es_epqTuple[], send the
>> query and receive the result during the callback routine.
> Do you mind that FDW cannot generate a plan so that make a tuple
> from eqpTules then apply fdw_quals from predefined executor
> nodes?
No. Please see my previous email. Sorry for my unfinished email.
Best regards,
Etsuro Fujita
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2015-11-12 11:49:43 | Re: WIP: Rework access method interface |
Previous Message | Etsuro Fujita | 2015-11-12 10:02:57 | Re: Minor comment improvement to create_foreignscan_plan |