Re: Foreign join pushdown vs EvalPlanQual

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.10202@lab.ntt.co.jp