Re: Optimization for updating foreign tables in Postgres FDW

Robert Haas <robertmhaas@gmail.com> writes:
> Overall, I think this is looking pretty good.

I hadn't been paying any attention to this thread, but I wonder whether
this entire approach isn't considerably inferior to what we can do now
with the planner pathification patch.  To quote from the new docs:
  PlanForeignModify and the other callbacks described in Section 54.2.3  are designed around the assumption that the
foreignrelation will be  scanned in the usual way and then individual row updates will be driven  by a local
ModifyTableplan node. This approach is necessary for the  general case where an update requires reading local tables as
wellas  foreign tables. However, if the operation could be executed entirely by  the foreign server, the FDW could
generatea path representing that and  insert it into the UPPERREL_FINAL upper relation, where it would  compete against
theModifyTable approach. This approach could also be  used to implement remote SELECT FOR UPDATE, rather than using the
row locking callbacks described in Section 54.2.4. Keep in mind that a path  inserted into UPPERREL_FINAL is
responsiblefor implementing all  behavior of the query.
 

I don't really see anything that this patch does that wouldn't be better
done that way.  And I'd kind of like to get a working example of that type
of path insertion into 9.6, so that we can find out if we need any hooks
or callbacks that aren't there today.
        regards, tom lane