On Tue, Mar 17, 2015 at 8:34 PM, Robert Haas <robertmh...@gmail.com> wrote:
> 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. > > 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. > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
