On Tue, Mar 17, 2015 at 10:11 AM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote: >> A way to work around this is to leave the ForeignPaths (there can possibly be >> only one foreign path per join relation) in the joinrel without removing them. >> FDW should work on joining two relations if they have foreign paths in the list >> of paths, irrespective of whether the cheapest path is foreign join path or not. >> For the topmost joinrel, if the foreign path happens to be the cheapest one, the >> whole join tree will be pushed down. >> >> On the other thread implementing foreign join for postgres_fdw, >> postgresGetForeignJoinPaths(), is just looking at the cheapest path, which would >> cause the problem you have described above. >> > It might be an idea if foreign-scan path is not wiped out regardless of the > estimated cost, we will be able to construct an entirely remote-join path > even if intermediation path is expensive than local join. > A problem is, how to distinct these special paths from usual paths that are > eliminated on the previous stage once its path is more expensive.
Any solution that is based on not eliminating paths that would otherwise be discarded based on cost seems to me to be unlikely to be feasible. We can't complicate the core path-cost-comparison stuff for the convenience of FDW or custom-scan pushdown.
We already have a precedence here. We cache different cheapest paths e.g 439 struct Path *cheapest_startup_path; 440 struct Path *cheapest_total_path; 441 struct Path *cheapest_unique_path; 442 List *cheapest_parameterized_paths;
All we have to do is add yet another there "cheapest_foreign_path" which can be NULL like cheapest_unique_path.