DELETE FROM fsck_log

dormando dormando at
Sun Oct 14 04:14:24 UTC 2007

> 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.


More information about the mogilefs mailing list