On Mon, Oct 06, 2003 at 02:23:05PM -0500, Jamie Becker wrote: [...] > One thing that would dramatically increase performance would be to change the > db schema; of course, this would be a big operation since dbmail is in > production, so I'm actually considering writing yet another IMAP server. > 1) separate the message headers (perhaps also parse out the most common ones) > into separate fields in the db. this would allow faster sorting and mailbox > listing and wouldn't require parsing a full TEXT field just to get a mailbox > listing.
There was a discussion about this on the list a few months back. I think almost everyone was in agreement that this is a good idea. > 2) move all or larger (>32K) message bodies to disk or at least to a separate > table. again, this would dramatically enhance performance where indexes might > oitherwise get bogged down on inserting and possibly selecting, and probably > speed performance on inbox listings etc as well. (especially full text > indexes on the message bodies.) I'd prefer to keep all the messages in the database. I don't know if there would be a significant performance increase. I guess it depends on the database/table handler. Are IMAP searches compatible with full text searches, the logic can be implemented in SQL? > (as i said, i'm thinking about taking the existing python imap server code in > twisted matrix and writing a new dbmail-server engine around it with > pluggable backend message stores. the performance might not be as high > (python vs straight c) but the long term maintenance would be better and it'd > be easier to optimize.) Has anyone looked at the code for any other imap servers? Is it modular enough to plugin a sql based message store? UW-IMAP supports a few different mailbox drivers. How tightly coupled is dbmail's imap handling code and sql handling code? xn
