Re: Foreign join pushdown vs EvalPlanQual - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: Foreign join pushdown vs EvalPlanQual
Date
Msg-id 20151112.161009.232859835.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: Foreign join pushdown vs EvalPlanQual  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Responses Re: Foreign join pushdown vs EvalPlanQual
List pgsql-hackers
Hello,


> > I really don't see why you're fighting on this point.  Making this a
> > generic feature will require only a few extra lines of code for FDW
> > authors.  If this were going to cause some great inconvenience for FDW
> > authors, then I'd agree it isn't worth it.  But I see zero evidence
> > that this is actually the case.
> 
> Really?  I think there would be not a little burden on an FDW author;
> when postgres_fdw delegates to the subplan to the remote server, for
> example, it would need to create a remote join query by looking at
> tuples possibly fetched and stored in estate->es_epqTuple[], send the
> query and receive the result during the callback routine.

Do you mind that FDW cannot generate a plan so that make a tuple
from eqpTules then apply fdw_quals from predefined executor
nodes?

The returned tuple itself can be stored in fdw_private as I think
Kiagai-san said before. So it is enough if we can fabricate a
Result node outerPlan of which is ForeignScan, which somehow
returns the tuple to examine.

I should be missing something, though.

regards,

> Furthermore, what I'm most concerned about is that wouldn't be
> efficient.  So, my question about that approach is whether FDWs really
> do some thing like that during the callback routine, instead of
> performing a secondary join plan locally.  As I said before, I know
> that KaiGai-san considers that that approach would be useful for
> custom joins.  But I see zero evidence that there is a good use-case
> for an FDW.
> 
> > From my point of view I'm now
> > thinking this solution has two parts:
> >
> > (1) Let foreign scans have inner and outer subplans.  For this
> > purpose, we only need one, but it's no more work to enable both, so we
> > may as well.  If we had some reason, we could add a list of subplans
> > of arbitrary length, but there doesn't seem to be an urgent need for
> > that.
> >
> > (2) Add a recheck callback.
> >
> > If the foreign data wrapper wants to adopt the solution you're
> > proposing, the recheck callback can call
> > ExecProcNode(outerPlanState(node)).  I don't think this should end up
> > being more than a few lines of code, although of course we should
> > verify that.  So no problem: postgres_fdw and any other FDWs where the
> > remote side is a database can easily delegate to a subplan, and
> > anybody who wants to do something else still can.
> >
> > What is not to like about that?

-- 
Kyotaro Horiguchi
NTT Open Source Software Center




pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: proposal: multiple psql option -c
Next
From: Michael Paquier
Date:
Subject: Re: pageinspect patch, for showing tuple data