> On Wed, Mar 18, 2015 at 2:34 AM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote:
> > So, overall consensus for the FDW hook location is just before the set_chepest()
> > at standard_join_search() and merge_clump(), isn't it?
>
> Yes, I think so.
>
> > 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.
>
> Great, thanks!
>
> One issue, which I think Ashutosh alluded to upthread, is that we need
> to make sure it's not unreasonably difficult for foreign data wrappers
> to construct the FROM clause of an SQL query to be pushed down to the
> remote side. It should be simple when there are only inner joins
> involved, but when there are all outer joins it might be a bit
> complex. It would be very good if someone could try to write that
> code, based on the new hook locations, and see how it turns out, so
> that we can figure out how to address any issues that may crop up
> there.
>
Here is an idea that provides a common utility function that break down
the supplied RelOptInfo of joinrel into a pair of join-type and a list of
baserel/joinrel being involved in the relations join. It intends to be
called by FDW driver to list up underlying relations.
IIUC, root->join_info_list will provide information of how relations are
combined to the upper joined relations, thus, I expect it is not
unreasonably complicated way to solve.
Once a RelOptInfo of the target joinrel is broken down into multiple sub-
relations (N>=2 if all inner join, elsewhere N=2), FDW driver can
reference the RestrictInfo to be used in relations join.
Anyway, I'll try to investigate the existing code for more detail today,
to clarify whether the above approach is feasible.
Thanks,
--
NEC OSS Promotion Center / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>