On 2015/11/19 12:32, Robert Haas wrote:
On Tue, Nov 17, 2015 at 8:47 PM, Kouhei Kaigai <kai...@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.1070...@lab.ntt.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
