Re: Foreign join pushdown vs EvalPlanQual

> -----Original Message-----
> From: Etsuro Fujita [mailto:fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)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(dot)etsuro(at)lab(dot)ntt(dot)co(dot)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/9A28C8860F777E439AA12E8AEA7694F8010F20AD@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 <kaigai(at)ak(dot)jp(dot)nec(dot)com>