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