<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">But, uh. This is bizarre enough that I'd like to run it by anyone else<br>on the list before committing. Any reason _not_ to prefer 'TRUNCATE
<br>TABLE fsck_log' here? Postgres?</blockquote><div><br>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.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The fsck_log tables I've been having in "production" are always over a<br>few million rows :)<br></blockquote></div><br>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.<br><br>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.
<br><br clear="all"><br>-- <br>Mark Smith / xb95<br><a href="mailto:smitty@gmail.com">smitty@gmail.com</a>