Hello, > -----Original Message----- > From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp] > Sent: Friday, September 11, 2015 2:05 PM > To: robertmh...@gmail.com > Cc: fujita.ets...@lab.ntt.co.jp; Kaigai Kouhei(海外 浩平); > pgsql-hackers@postgresql.org; shigeru.han...@gmail.com > Subject: Re: [HACKERS] Foreign join pushdown vs EvalPlanQual > > Hello, > > At Thu, 10 Sep 2015 17:24:00 -0400, Robert Haas <robertmh...@gmail.com> wrote > in <CA+TgmobxksR2=3wEdY5cEgpd1hQ6Z0WoZEBBoxgs=xkzpbf...@mail.gmail.com> > > On Thu, Sep 3, 2015 at 1:22 AM, Etsuro Fujita > > <fujita.ets...@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 <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
