Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)

2015/03/25 19:47、Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)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.

—
Shigeru HANADA