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

> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Tue, Mar 17, 2015 at 10:11 AM, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:
> >> 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.
>
> I concur. I'm not even so worried about the cost of add_path as such;
> the real problem with not discarding paths as aggressively as possible
> is that it will result in a combinatorial explosion in the number of
> path combinations that have to be examined at higher join levels.
>
I'm inclined to agree. It is also conclusion of the discussion with Hanada-san
yesterday, due to the number of paths to be considered and combination problems,
as you mentioned above.

So, overall consensus for the FDW hook location is just before the set_chepest()
at standard_join_search() and merge_clump(), isn't it?
Let me make a design of FDW hook to reduce code duplications for each FDW driver,
especially, to identify baserel/joinrel to be involved in this join.

Thanks,
--
NEC OSS Promotion Center / PG-Strom Project
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>