Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)

On Tue, Mar 17, 2015 at 8:34 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Tue, Mar 17, 2015 at 10:11 AM, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)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