On Tue, Mar 17, 2015 at 10:11 AM, Kouhei Kaigai <kai...@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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
