Aaron Stone wrote: > 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. > I was thinking that new emails might well come in to a standard type non-compressed table then emails can be moved to archive over time. I spose it would be possible to even just do it based on date. IE all emails over 30 days get moved into 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 > I was thinking that but (hopefully) most of the stuff that gets emailed as attachments should already be compressed, perhaps it can attempt compressing it see if it makes a difference and if not just mark it as done and leave it as is. I'm intrigued by the speedup given through the compression for the fast cpu slow disk case. HDD transfer rates haven't been going up that fast and quad core CPU's are coming soon to a desktop near you. I wonder if its possible to (magically) fulltext index a part then compress it. Expand it only after you have found it. On the side of implementation. Perhaps if there is support for dedicated "archive" tables (basically a copy of the storage tables now) then you could make the database itself be mounted on a compressed volume or some such. Not too sure how badly the DB's would hate that. _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
