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

From Kouhei Kaigai
Subject Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)
Date
Msg-id 9A28C8860F777E439AA12E8AEA7694F8010C6D81@BPXM15GP.gisp.nec.co.jp
Whole thread Raw
In response to Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Responses Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)
List pgsql-hackers
> On Wed, Mar 25, 2015 at 3:14 PM, Shigeru HANADA <shigeru.hanada@gmail.com> wrote:
>     Or bottom of make_join_rel().  IMO build_join_rel() is responsible for
> just building (or searching from a list) a RelOptInfo for given relids.  After
> that make_join_rel() calls add_paths_to_joinrel() with appropriate arguments per
> join type to generate actual Paths implements the join.  make_join_rel() is
> called only once for particular relid combination, and there SpecialJoinInfo and
> restrictlist (conditions specified in JOIN-ON and WHERE), so it seems promising
> for FDW cases.
> 
> 
> 
> I like that idea, but I think we will have complex hook signature, it won't remain
> as simple as hook (root, joinrel).
> 
In this case, GetForeignJoinPaths() will take root, joinrel, rel1, rel2,
sjinfo and restrictlist.
It is not too simple, but not complicated signature.

Even if we reconstruct rel1 and rel2 using sjinfo, we also need to compute
restrictlist using build_joinrel_restrictlist() again. It is a static function
in relnode.c. So, I don't think either of them has definitive advantage from
the standpoint of simplicity.

Thanks,
--
NEC OSS Promotion Center / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>


pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)
Next
From: Amit Kapila
Date:
Subject: Re: possible dsm bug in dsm_attach()