(2014/06/14 2:46), Tom Lane wrote: > Jason Petersen <ja...@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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
