> -----Original Message----- > From: Etsuro Fujita [mailto:fujita.ets...@lab.ntt.co.jp] > Sent: Friday, September 11, 2015 12:36 PM > To: Robert Haas > Cc: Kaigai Kouhei(海外 浩平); PostgreSQL-development; 花田茂 > Subject: Re: [HACKERS] Foreign join pushdown vs EvalPlanQual > > On 2015/09/11 6:24, Robert Haas wrote: > > 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 proposed the following API changes: > > * I modified create_foreignscan_path, which is called from > postgresGetForeignJoinPaths/postgresGetForeignPaths, so that a path, > subpath, is passed as the eighth argument of the function. subpath > represents a local join execution path if scanrelid==0, but NULL if > scanrelid>0. > I like to suggest to have multiple path nodes, like custom-scan, because the infrastructure will be also helpful to implement FDW driver that can have multiple sub-plans. One expected usage is here: http://www.postgresql.org/message-id/9a28c8860f777e439aa12e8aea7694f8010f2...@bpxm15gp.gisp.nec.co.jp
> * I modified make_foreignscan, which is called from > postgresGetForeignPlan, so that a list of quals, fdw_quals, is passed as > the last argument of the function. fdw_quals represents remote quals if > scanrelid>0, but NIL if scanrelid==0. > If a callback on ForeignRecheck processes EPQ rechecks, the core PostgreSQL don't need to know what expression was pushed down and how does it kept in the private field (fdw_exprs). Only FDW driver knows which private field is the expression node that was pushed down to the remote side. It shall not be an interface contract. 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
