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
