(2012/02/21 20:25), Etsuro Fujita wrote:
> Please find attached an updated version of the patch.
This v2 patch can be applied on HEAD cleanly. Compile completed with
only one expected warning of scan.c, and all regression tests for both
core and contrib modules passed.
This patch allows FDWs to return multiple ForeignPath nodes per a
PlanForeignScan call. It also get rid of FdwPlan, FDW-private
information container, by replacing with simple List.
I've reviewed the patch closely, and have some comments about its design.
Basically a create_foo_path is responsible for creating a node object
with a particular Path-derived type, but this patch changes
create_foreignscan_path to just call PlanForeignScan and return void.
This change seems breaking module design. IMO create_foreignscan_path
should return just one ForeignPath node per a call, so calling add_path
multiple times should be done in somewhere else. I think
set_foreign_pathlist suites for it, because set_foo_pathlist functions
are responsible for building possible paths for a RangeTblEntry, as
comment of set_foreign_pathlist says.
/*
* set_foreign_pathlist
* Build one or more access paths for a foreign table RTE
*/
In this design, FDW authors can implement PlanForeignScan by repeating
steps below for each possible scan path for a foreign table:
(1) create a template ForeignPath node with create_foreignscan_path
(2) customize the path as FDW wants, e.g. push down WHERE clause
(3) store FDW-private info
(4) estimate costs of the path
(5) call add_path to add the path to RelOptInfo
Current design doesn't allow FDWs to provide multiple paths which have
different local filtering from each other, because all paths share a
RelOptInfo and baserestrictinfo in it. I think this restriction
wouldn't be a serious problem.
Please find attached a patch implementing the design above.
--
Shigeru Hanada