DELETE FROM fsck_log

[dormando]

> The only reason I'd toss out here is that TRUNCATE TABLE's functionality 
> varies depending on your storage engine, version of MySQL, etc.  Unless 
> you build in rules about when to use it or restrict MogileFS to MySQL 
> 5.0+ on InnoDB it doesn't seem worth the potential gain for this very 
> specific situation.

Older version of MySQL essentially map it to 'DELETE FROM table', so the 
functionality should be the same. You can even kill it and it'll roll 
back! :)

> I'd expect it to be a big hit to just say good-bye to millions of rows 
> regardless of which you use?  Maybe TRUNCATE TABLE is fast enough with 
> MySQL 5.0+, but DELETE is definitely not.  I've always done lazy 
> deletes, deleting some number of rows every $time_period.
> 
> If you wanted you could have a tunable that says 
> "enable_truncate_table", but that seems a bit too micro-management-y.  
> It's not going to hurt you much to have those fsck_log rows hang out for 
> a bit while you neuter them a thousand rows at a time, IMHO.

TRUNCATE table is fast under 5.0+. It's mapped to a 'DROP TABLE blah; 
CREATE TABLE blah' for innodb. I have no clue about postgres.

So normally I do use the DELETE FROM blah LIMIT 5000 or whatnot in a 
loop but I'm not sure if it's necessary in this case? At least, I can't 
come up with a compelling reason to not just switch it to truncate table 
vs having the client slowly delete the rows. Currently it's an issue 
because "mogadm fsck clearlog" blindly issues this :)

It's important that this work at any rate. If there's no (postgres? 
autoinc? anything?) issue I'll just switch it to TRUNCATE and keep the 
mogadm fsck clearlog functionality the same.

-Dormando