|From:||Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>|
|To:||Robert Haas <robertmhaas(at)gmail(dot)com>, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>|
|Cc:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>|
|Subject:||Re: Foreign join pushdown vs EvalPlanQual|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2015/11/19 12:32, Robert Haas wrote:
> On Tue, Nov 17, 2015 at 8:47 PM, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:
>> The attached patch is the portion cut from the previous EPQ recheck
> Thanks, committed.
Thanks, Robert and KaiGai-san.
Sorry, I'm a bit late to the party. Here are my questions:
* This patch means we can define fdw_recheck_quals even for the case of
foreign tables with non-NIL fdw_scan_tlist. However, we discussed in
another thread  that such foreign tables might break EvalPlanQual
tests. Where are we on that issue?
* For the case of foreign joins, I think fdw_recheck_quals can be
defined for example, the same way as for the case of foreign tables, ie,
quals not in scan.plan.qual, or ones defined as "otherclauses"
(rinfo->is_pushed_down=true) pushed down to the remote. But since it's
required that the FDW has to add to the fdw_scan_tlist the set of
columns needed to check quals in fdw_recheck_quals in preparation for
EvalPlanQual tests, it's likely that fdw_scan_tlist will end up being
long, leading to an increase in a total data transfer amount from the
remote. So, that seems not practical to me. Maybe I'm missing
something, but what use cases are you thinking?
|Next Message||Robert Haas||2015-11-20 13:36:50||Re: [DESIGN] ParallelAppend|
|Previous Message||Taiki Kondo||2015-11-20 12:05:38||Re: [Proposal] Table partition + join pushdown|