(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