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