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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
