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

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company