Re: Clarification of FDW API Documentation

(2014/06/14 2:46), Tom Lane wrote:
> Jason Petersen <jason(at)citusdata(dot)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 plan tree generated for UPDATE/DELETE will always
* include a ForeignScan that retrieves ctids (using SELECT FOR UPDATE)
* and then the ModifyTable node will have to execute individual remote
* UPDATE/DELETE commands. If there are no local conditions or 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