On 2015/11/20 22:45, Kouhei Kaigai wrote: I wrote:
* 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?
In case of later locking, RefetchForeignRow() will set a base tuple that have compatible layout of the base relation, not fdw_scan_tlist, because RefetchForeignRow() does not have information about scan node.
IIUC, I think the base tuple would be stored into EPQ state not only in case of late row locking but in case of early row locking.
* 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?
It is trade-off. What solution do you think we can have? To avoid data transfer used for EPQ recheck only, we can implement FDW driver to issue remote join again on EPQ recheck, however, it is not a wise design, isn't it? If we would be able to have no extra data transfer and no remote join execution during EPQ recheck, it is a perfect.
I was thinking that in an approach using a local join execution plan, I would just set fdw_recheck_quals set to NIL and evaluate the otherclauses as part of the local join execution plan, so that fdw_scan_tlist won't end up being longer, as in the patch [1]. (Note that in that patch, remote_exprs==NIL when calling make_foreignscan during postgresGetForeignPlan in case of foreign joins.)
Best regards, Etsuro Fujita [1] http://www.postgresql.org/message-id/5624d583.10...@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
