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.
>
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 <kaigai(at)ak(dot)jp(dot)nec(dot)com>