On Mon, 2007-06-04 at 20:23 +1000, Jake Anderson wrote: > > > > The proposed schema has some merit, but I would rather setup two new tables > > (partslists and mimeparts) which would be functionally like Jonathan's two > > tables. Main difference is I want to leave the current tables as they are: > > new > > messages get inserted into the new setup, and old messages are left in the > > old > > format until converted by a lo-pri run of dbmail-util. The message retrieval > > code would then first try to reconstruct the message from the new tables and > > failing that use the 'old' current setup. > > > While we are talking about adding tables has anybody thought of using > archive type tables?
Not I! :-) > As our data is stuff that generally compresses well and doesn't change > much compressed type tables could also lead to some significant storage > savings. Obviously its not for everybody but if we are talking about > scanning multiple tables for records anyway ;-> > Perhaps its something that could be done with flags? If you flag an imap > folder as "archive" then stuff in it will get shuffled into a different > table by the util? with any luck this should avoid the performance hit > of having to scan 2 tables all the time for the data. This would be a really interesting use case for folder annotations. Not sure what you mean by scanning two tables. Do you mean the partslist / mimeparts tables? Because of the relational model, indexes and the fact that many IMAP queries request individual IMAP parts rather than the entire message, this should be extremely fast. I would expect a moderate speedup, rather than any performance hit. > Its probably not a good idea to compress the data outside of the storage > engine (ie in the dbmail SW itself) as you would probably loose indexing > and the like (and full text indexing/searching would probably be the > greatest use of the archive) According to the caveats listed here: http://dev.mysql.com/doc/refman/5.1/en/archive-storage-engine.html it might be a better design to implement compression from within DBMail of the mime part contents, and leave everything else uncompressed. For the few times a year when you need to dig out a really old email, having the indexes available will be very nice. Aaron _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
