Christopher Browne wrote:
> I'll be running against groups of 100 and against groups of 1 
> overnight; presumably both will be worse than my other numbers.  It'll 
> be interesting to see how much worse than 4:50 it gets...

hundreds.log
-------------------------------------------------------
Started
Tue Jul  3 22:03:16 UTC 2007
Started purging by hundreds
Tue Jul  3 22:04:59 UTC 2007
Completed deletions
Tue Jul  3 22:08:14 UTC 2007
=======================================================
oneatatime.log
-------------------------------------------------------
Started
Tue Jul  3 22:08:15 UTC 2007
Started purging by oneatatime
Tue Jul  3 22:09:50 UTC 2007
Completed deletions
Tue Jul  3 22:25:01 UTC 2007
=======================================================
onedelete.log
-------------------------------------------------------
Started
Tue Jul  3 21:57:04 UTC 2007
Started purging by onedelete
Tue Jul  3 21:58:41 UTC 2007
Completed deletions
Tue Jul  3 21:59:24 UTC 2007
=======================================================
thousands.log
-------------------------------------------------------
Started
Tue Jul  3 21:47:07 UTC 2007
Started purging by thousands
Tue Jul  3 21:47:22 UTC 2007
Completed deletions
Tue Jul  3 21:53:12 UTC 2007
=======================================================


One at a time took about 15 minutes
100 at a time took 3:15
1000 at a time took longer than 100 at a time (curious, that!)
all in one shot took 43 seconds.

Something's fishy about the 1K at a time case; I'm rerunning that.  
Retrying, it took 4:22, again, longer than at 100/DELETE.

I expect that we run into some parsing overhead where doing 1000 at a 
shot imposes some burden (memory, query plan, whatever) that is greater 
than the savings gotten from cutting down on the number of queries.

There is definitely a material savings to be had; deleting a bunch of 
tuples in one query *does* provide a considerable savings over doing one 
at a time.  Whether it's worth implementing may be another question :-).