Re: Foreign join pushdown vs EvalPlanQual
От | Etsuro Fujita |
---|---|
Тема | Re: Foreign join pushdown vs EvalPlanQual |
Дата | |
Msg-id | 564F0EDB.1080301@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Foreign join pushdown vs EvalPlanQual (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Foreign join pushdown vs EvalPlanQual
|
Список | 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 по дате отправления: