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

From Etsuro Fujita
Subject Re: Foreign join pushdown vs EvalPlanQual
Date
Msg-id 564F0EDB.1080301@lab.ntt.co.jp
Whole thread Raw
In response to Re: Foreign join pushdown vs EvalPlanQual  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Foreign join pushdown vs EvalPlanQual  (Kouhei Kaigai <kaigai@ak.jp.nec.com>)
List pgsql-hackers
On 2015/11/19 12:32, Robert Haas wrote:
> On Tue, Nov 17, 2015 at 8:47 PM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote:
>> The attached patch is the portion cut from the previous EPQ recheck
>> patch.

> 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 [1] 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?

Best regards,
Etsuro Fujita

[1] http://www.postgresql.org/message-id/55AF3C08.1070409@lab.ntt.co.jp




pgsql-hackers by date:

Previous
From: Taiki Kondo
Date:
Subject: Re: [Proposal] Table partition + join pushdown
Next
From: Robert Haas
Date:
Subject: Re: [DESIGN] ParallelAppend