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.
The Enterprise PostgreSQL Company
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: