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

On Sat, Mar 14, 2015 at 10:37 PM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote:
> From the standpoint of extension development, I'm uncertain whether we
> can easily reproduce information needed to compute alternative paths on
> the hook at standard_join_search(), like a hook at add_paths_to_joinrel().
>
> (Please correct me, if I misunderstood.)
> For example, it is not obvious which path is inner/outer of the joinrel
> on which custom-scan provider tries to add an alternative scan path.

That's a problem for the GPU-join use case, where you are essentially
trying to add new join types to the system.  But it's NOT a problem if
what you're actually trying to do is substitute a *scan* from a
*join*.  If you're going to produce the join output by scanning a
materialized view, or by scanning the results of a query pushed down
to a foreign server, you don't need to divide the rels into inner rels
and outer rels; indeed, any such division would be artificial.  You
just need to generate a query that produces the right answer *for the
entire joinrel* and push it down.

I'd really like to hear what the folks who care about FDW join
pushdown think about this hook placement issue.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company