> On Fri, Nov 20, 2015 at 12:11 AM, Kouhei Kaigai <kai...@ak.jp.nec.com> wrote: > >> On Thu, Nov 19, 2015 at 6:39 AM, Kouhei Kaigai <kai...@ak.jp.nec.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- > >> 14ykfkgkr...@mail.gmail.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 <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
