> On Tue, Nov 17, 2015 at 10:22 PM, Kouhei Kaigai <kai...@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 <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
