> On Tue, Nov 17, 2015 at 10:22 PM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote:
> > Apart from EPQ rechecks, the above aggressive push-down idea allows to send
> > contents of multiple relations to the remote side. In this case, ForeignScan
> > needs to have multiple sub-plans.
> >
> > For example, please assume here is three relations; tbl_A and tbl_B are
> > local and small, tbl_F is remote and large.
> > In case when both of (tbl_A JOIN tbl_F) and (tbl_B JOIN tbl_F) produces
> > large number of rows thus consumes deserved amount of network traffic but
> > (tbl_A JOIN tbl_B JOIN tbl_F) produce small number of rows, the optimal
> > strategy is to send local contents to the remote side once then run
> > a remote query here to produce relatively smaller rows.
> > In the implementation level, ForeignScan shall represent (tbl_A JOIN tbl_B
> > JOIN tbl_F), then it returns a bunch of joined tuples. Its remote query
> > contains VALUES(...) clauses to pack contents of the tbl_A and tbl_B, thus,
> > it needs to be capable to execute underlying multiple scan plans and fetch
> > tuples prior to remote query execution.
>
> Hmm, maybe. I'm not entirely sure multiple subplans is the best way
> to implement that, but let's argue about that another day.
>
So, are you suggesting to make a patch that allows ForeignScan to have
multiple sub-plans right now? Or, one sub-plan?
Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>