> 2015/03/25 19:47、Kouhei Kaigai <kai...@ak.jp.nec.com> のメール： > > The reason why FDW handler was called multiple times on your example is, > > your modified make_join_rel() does not check whether build_join_rel() > > actually build a new RelOptInfo, or just a cache reference, doesn't it? > > > > Yep. After that change calling count looks like this: > > fdw=# explain select * from pgbench_branches b join pgbench_tellers t on t.bid > = b.bid join pgbench_accounts a on a.bid = b.bid and a.bid = t.bid; > INFO: postgresGetForeignJoinPaths() 1x2 > INFO: postgresGetForeignJoinPaths() 1x4 > INFO: postgresGetForeignJoinPaths() 2x4 > INFO: standard_join_search() old hook point > INFO: standard_join_search() old hook point > INFO: standard_join_search() old hook point > INFO: postgresGetForeignJoinPaths() 0x4 > INFO: standard_join_search() old hook point > QUERY PLAN > --------------------------------------------------------- > Foreign Scan (cost=100.00..102.11 rows=211 width=1068) > (1 row) > > fdw=# > > > If so, I'm inclined to your proposition. > > A new "bool *found" argument of build_join_rel() makes reduce number of > > FDW handler call, with keeping reasonable information to build remote- > > join query. > > Another idea is to pass “found” as parameter to FDW handler, and let FDW to > decide > to skip or not. Some of FDWs (and some of CSP?) might want to be conscious of > join combination. > I think it does not match the concept we stand on. Unlike CSP, FDW intends to replace an entire join sub-tree that is represented with a particular joinrel, regardless of the sequence to construct a joinrel from multiple baserels. So, it is sufficient to call GetForeignJoinPaths() once a joinrel is constructed, isn't it?
Thanks, -- NEC OSS Promotion Center / 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
