Re: Foreign join pushdown vs EvalPlanQual

Hello,

At Thu, 10 Sep 2015 17:24:00 -0400, Robert Haas <robertmhaas(at)gmail(dot)com> wrote in <CA+TgmobxksR2=3wEdY5cEgpd1hQ6Z0WoZEBBoxgs=XKZpbfUXA(at)mail(dot)gmail(dot)com>
> 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 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.

Is this pointless?

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center