Re: Foreign join pushdown vs EvalPlanQual

> On Fri, Nov 20, 2015 at 12:11 AM, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:
> >> On Thu, Nov 19, 2015 at 6:39 AM, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:
> >> > So, are you suggesting to make a patch that allows ForeignScan to have
> >> > multiple sub-plans right now? Or, one sub-plan?
> >>
> >> Two:
> >>
> http://www.postgresql.org/message-id/CA+TgmoYZeje+ot1kX4wdoB7R7DPS0CWXAzfqZ-
> >> 14yKfkgKREAQ(at)mail(dot)gmail(dot)com
> >>
> > Hmm. Two is a bit mysterious for me because two sub-plans (likely)
> > means this ForeignScan node checks join clauses and reconstruct
> > a joined tuple by itself but does not check scan clauses pushed-
> > down (it is job of inner/outer scan plan, isn't it?).
> > In this case, how do we treat N-way remote join cases (N>2) if we
> > assume such a capability in FDW driver?
> >
> > One subplan means FDW driver run an entire join sub-tree with local
> > alternative sub-plan; that is my expectation for the majority case.
> > However, I cannot explain two subplans, but not multiple, well.
>
> What I'm imagining is that we'd add handling that allows the
> ForeignScan to have inner and outer children. If the FDW wants to
> delegate the EvalPlanQual handling to a local plan, it can use the
> outer child for that. Or the inner one, if it likes. The other one
> is available for some other purposes which we can't imagine yet. If
> this is too weird, we can only add handling for an outer subplan and
> forget about having an inner subplan for now.
>
I'd like to agree the last sentence. Having one sub-plan is better
(but the second best from my standpoint) than fixed two subplans,
because ...

> I just thought to make
> it symmetric, since outer and inner subplans are pretty deeply baked
> into the structure of the system.
>
Yep, if we would have a special ForeignJoinPath to handle two foreign-
tables join, it will be natural. However, our choice allows N-way join
at once if sub-plan is consists of three or more foreign-tables.
In this case, ForeignScan (scanrelid==0) can represents a sub-plan that
shall be equivalent to a stack of joins; that looks like a ForeignScan
has inner, outer and variable number of "middler" input streams.

If and when we assume ForeignScan has own join mechanism but processes
scan-qualifiers by local sub-plans, fixed-number sub-plans are not
sufficient. (Probably, it is minority case although.)

I'm inclined to put just one outer path at this moment, because the
purpose of the FDW sub-plans is EPQ recheck right now. So, we will
be able to enhance the feature when we implement other stuffs - more
aggressive join push-down for example.

Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>