Hello,
> -----Original Message-----
> From: Kyotaro HORIGUCHI [mailto:horiguchi.kyotaro@lab.ntt.co.jp]
> Sent: Friday, September 11, 2015 2:05 PM
> To: robertmhaas@gmail.com
> Cc: fujita.etsuro@lab.ntt.co.jp; Kaigai Kouhei(海外 浩平);
> pgsql-hackers@postgresql.org; shigeru.hanada@gmail.com
> Subject: Re: [HACKERS] Foreign join pushdown vs EvalPlanQual
>
> Hello,
>
> At Thu, 10 Sep 2015 17:24:00 -0400, Robert Haas <robertmhaas@gmail.com> wrote
> in <CA+TgmobxksR2=3wEdY5cEgpd1hQ6Z0WoZEBBoxgs=XKZpbfUXA@mail.gmail.com>
> > On Thu, Sep 3, 2015 at 1:22 AM, Etsuro Fujita
> > <fujita.etsuro@lab.ntt.co.jp> wrote:
> > >> I'm wondering if there's another approach. If I understand correctly,
> > >> there are two reasons why the current situation is untenable. The
> > >> first is that ForeignRecheck always returns true, but we could instead
> > >> call an FDW-supplied callback routine there. The callback could be
> > >> optional, so that we just return true if there is none, which is nice
> > >> for already-existing FDWs that then don't need to do anything.
> > >
> > > My question about this is, is the callback really needed? If there are any
> > > FDWs that want to do the work *in their own way*, instead of just doing
> > > ExecProcNode for executing a local join execution plan in case of foreign
> > > join (or just doing ExecQual for checking remote quals in case of foreign
> > > table), I'd agree with introducing the callback, but if not, I don't think
> > > that that makes much sense.
> >
> > It doesn't seem to me that it hurts much of anything to add the
> > callback there, and it does provide some flexibility. Actually, I'm
> > not really sure why we're thinking we need a subplan here at all,
> > rather than just having a ForeignRecheck callback that can do whatever
> > it needs to do with no particular help from the core infrastructure.
> > I think you wrote some code to show how postgres_fdw would use the API
> > you are proposing, but I can't find it. Can you point me in the right
> > direction?
>
> I've heard that the reason for the (fs_)subplan is that it should
> be initialized using create_plan_recurse, set_plan_refs and
> finalyze_plan (or others), which are static functions in the
> planner, unavailable in fdw code.
>
It was a discussion when custom-scan/join interface got merged, because
I primarily designed the interface to call create_plan_recurse() from
the extension, however, we concluded that we keep this function as static
and tells the core a bunch of path-nodes to be initialized.
It also reduced interface complexity because we can omit callbacks to
be placed on the setrefs.c and subselect.c.
Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>
