> On Tue, Nov 17, 2015 at 6:51 PM, Kouhei Kaigai <kai...@ak.jp.nec.com> wrote: > > It just intends to keep code symmetry with custom-scan case, so not > > a significant reason. > > And, I expected ForeignScan will also need multiple sub-plans soon > > to support more intelligent push-down like: > > > http://www.postgresql.org/message-id/9A28C8860F777E439AA12E8AEA7694F8010F47D > a...@bpxm15gp.gisp.nec.co.jp > > I might be missing something, but why would that require multiple child plans? > 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. So, ForeignScan may also have multiple sub-plans. Of course, it is an independent feature from the EPQ rechecks. It is not a matter even if we will extend this field later. 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
