On Mar 19, 1:23*am, ThanksButNo <no.no.tha...@gmail.com> wrote:
> After all, an I/O is an I/O, and the system is going to pull down a
> block, modify it, and put it back, no matter whether that's an update
> or a delete.
>
> And, although I'm not expert on database internals, I'd be willing to
> bet that internally the system just flags the row for deletion
> anyway. *Then later on, as time and algorithms permit, it puts the row
> back into the pool of available space. *So all you'd accomplish with
> your flag is duplicating the internal actions, and not saving hardly
> anything at all.

Well after doing some more reading last night I found the following on
the mysql site:

"If a MyISAM table has no holes in the data file (deleted rows in the
middle), inserts can be performed to add rows to the end of the table
at the same time that SELECT statements are reading rows from the
table."
(http://dev.mysql.com/doc/refman/5.1/...t-inserts.html)

This would perhaps give a potential speed increase by preventing holes
due to deletions? Any new insert will automatically to the end of the
table and so won't interfere with SELECTs.

It does go on to say that this behaviour can be forced though with the
concurrent_inserts variable. I guess the undelete option is the best
argument for the practice so far.