Re: Optimization for updating foreign tables in Postgres FDW

* Albe Laurenz (laurenz.albe@wien.gv.at) wrote:
> Etsuro Fujita wrote:
> > I agree with you on that point.  So, I've updated the patch to have the
> > explicit flag, as you proposed.  Attached is the updated version of the
> > patch.  In this version, I've also revised code and its comments a bit.
> 
> Thank you, I have set the patch to "Ready for Committer".

I had a few minutes, so I started looking at this patch and I definitely
like where it's going.  One concern which was brought up that I didn't
see completely addressed was around UPDATE/DELETE with LIMIT, which
seems to be making progress towards getting in.  Presumably, we'd simply
disallow this optimization in that case, but we'll need a way to
identify that case..

I have to admit that, while I applaud the effort made to have this
change only be to postgres_fdw, I'm not sure that having the
update/delete happening during the Scan phase and then essentially
no-op'ing the ExecForeignUpdate/ExecForeignDelete is entirely in-line
with the defined API.

I would have thought we'd add a capability check function that says "can
this Modify be completely pushed down" and then have a way for that to
happen in ExecForeignUpdate/ExecForeignDelete.  That means changes to
the existing API, of course, and if people feel that's unnecessary then
I'd suggest that we need to at least document that we're willing to
support these bulk operations happening on the remote siude during the
pre-Modify Scan and not during the ExecForeignUpdate/ExecForeignDelete.
Thanks,
	Stephen