Re: Clarification of FDW API Documentation

(2014/06/14 2:46), Tom Lane wrote:
> Jason Petersen <jason@citusdata.com> writes:

>> Even if there is no guarantee that `IterateForeignScan` is called exactly once
>> before each `ExecForeignDelete` call (which would remove the ability to have
>> them cooperate using this single cursor), one could easily devise other storage
>> backends that don't need "junk" columns to perform `DELETE` operations.
> 
> Such as?  I could imagine having an optimization that works like you
> suggest for simple scan cases, but it's not there now, and it could not
> be the only mode.

The optimization in the following comment for postgresPlanForeignModify?

/** postgresPlanForeignModify*      Plan an insert/update/delete operation on a foreign table** Note: currently, the
plantree generated for UPDATE/DELETE will always* include a ForeignScan that retrieves ctids (using SELECT FOR UPDATE)*
andthen the ModifyTable node will have to execute individual remote* UPDATE/DELETE commands.  If there are no local
conditionsor joins* needed, it'd be better to let the scan node do UPDATE/DELETE RETURNING* and then do nothing at
ModifyTable. Room for future optimization ...*/
 

I think this would be very useful.  So, I plan to add a patch for it to
2014-08.

Thanks,

Best regards,
Etsuro Fujita