> > 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? 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.
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) _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
