(2012/02/14 17:40), Etsuro Fujita wrote: > OK. But my question was about the PlanForeignScan API.
Sorry for misunderstanding. :( > As discussed at > that thread, it would have to change the PlanForeignScan API to let the > FDW generate multiple paths and dump them all to add_path instead of > returning a FdwPlan struct. With this change, I think it would also > have to add a new FDW API that is called from create_foreignscan_plan() > and lets the FDW generate foreignscan plan for the base relation scanned > by the best path choosed by postgres optimizer for itself. What do you > think about it? Though I have only random thoughts about this issue at the moment... Multiple valuable Paths for a scan of a foreign table by FDW, but changing PlanForeignScan to return list of FdwPlan in 9.2 seems too hasty. It would need more consideration about general interface for possible results such as: * Full output (no WHERE push-down) is expensive on both remote and transfer. * Filtered output (WHERE push-down) has cheap total costs when only few rows come through the filter. * Ordered output (ORDER BY push-down) is expensive on remote, but has chance to omit upper Sort node. * Aggregated output (GROUP BY push-down) is expensive on remote, but have chance to omit upper Agg node, and reduces data transfer. * Limited output (LIMIT/OFFSET push-down) can reduce data transfer, and have chance to omit upper Limit node. Currently FDWs can consider only first two, AFAIK. If FDW generates multiple FdwPlan (Full and Filtered) and sets different start-up costs and total costs to them (may be former has higher start-up and lower total than latter), planner would choose better for the whole plan. In addition to changing FdwRoutine, it seems worth changing FdwPlan too so that FDWs can return more information to planner, such as pathkeys and rows, for each possible path. In short, I have some ideas to enhance foreign table scans, but IMO they are half-baked and we don't have enough time to achieve them for 9.2. Regards, -- Shigeru Hanada -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers