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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
