> What I see here is that we are trying to come up with a special case 
> optimization for mass-deletes. No mass insert or update operations will 
> benefit from any of this. Do people do mass deletes that much that we 
> really have to worry about them?

I occasionally did such mass delete operations, which did cause slony to
lag behind but not so much that I would cry for such a feature...

In fact our postgres DB scaling is done by splitting the DB in 2 when
the customers on it grow too much. We do this by replicating a copy via
slony, and then cut the replication and configure half of the customers
to point to the first one, the rest point to the other one. Then delete
the unneeded data on both DBs. This procedure is transparent to the
customers, the required downtime is a few minutes while the application
is restarted with the new configuration, which can be done in a low
traffic period.

So back to the point, deleting the unneeded half of the data is such a
bulk delete operation, and sometimes I had to do it while slony was
active on the DB.

Cheers,
Csaba.