(2011/10/24 20:40), I wrote:
> I've found some issues for this CF item, and I would need some more
> effort to solve them. So I'll mark this item as "Returned with
> feedback", and I'll propose this idea again for next CF (2011-11).
This is the second effort for $SUBJECT. Attached patch requires
pgsql_fdw patches[1] to be applied previously. This patch provides:
* Changes for backend
* Add new planner node ForeignJoinPath and related routines. In
current design, planner consider all of possible join combinations
between foreign tables, similar to local joins such as nested loop,
hash join and merge join. And if foreign join is cheapest, planner
produces a ForeignScan plan node for a join. So executor is not
modified heavily since 9.1.
* Add new FDW callback for planning join push-down between foreign
tables on same server. This function is optional, and allowed to
return NULL to tell planner that that join can't be handled by the
FDW.
* Add server oid to RelOptInfo. This is useless at all for relations
other than foreign scan and foreign join, but it would reduces
catalog lookup during foreign scan/join planning.
* Add enable_foreignjoin GUC parameter. Join between foreign tables
is considered only when this parameter is on.
* Changes for pgsql_fdw
* Implemente PlanForeignJoin callback function.
[1]http://archives.postgresql.org/pgsql-hackers/2011-11/msg00904.php
Regards,
--
Shigeru Hanada