Sri Gupta wrote: > I'm running about 5000 mailboxes over ten domains, most with less than > 100 messages (though some of the imap users have 60-100,000). When I > was using postfix maildirs and courier-imap, the imap users with huge > mailboxes used to lock up the server when they did searches.. Now, > even with dbmail's less-than-optimal sql searching, it runs about > fifty times faster.
Warning: don't deploy 2.0 without my patch (or perhaps Paul's or both). See Xing's reports for confirmation - it will cause CPU hogging on mail checks from imap users. This is so at least if you're using mysql; I'm not sure about postgresql - my patch has no effect for it but Paul's may make things better; and I'm not sure postgres setups have this problem anyway. (Come to think of it, this alone should probably merit an immediate 2.01 version. It's a serious issue). The system probably does run faster, but the IMAP searches themselves are probably slow. This slowness, however, spends most of the time in queries so it leaves room for other users - unlike the previous setup. And, the searching itself is probably not slower than with courier. Or are the searches themselves actually faster? This would be a surprise, based on what I see in the code. > >But this is quite limited. And adding separate header tables could break > >the current code. > > > > > What about the proposed idea to have the header stored in a seperate > field in addition to the messageblks? dbmail could check for a field in > the header table, and if it doesn't exist for the message being grabbed, > use the old mechanism to parse (and copy the header to the header table > for future reference), or a hard upgrade could be done with a header > import script of some sort.. A checking won't do - this will mean checking ALL messages before any search. Only a "hard upgrade" - and after it, all messages imported into the system should be parsed and the additional header data should be stored. All of the functions that do message storing would need to be updated immediately for this to work. Also, functions that delete messages should be updated. (Actually, adding some fields is not enough because the header field set is not limited; we need adding tables. The key question, however, is not the details of the DB changes, but whether we can add the functionality without breaking current code). Yours, Mikhail Ramendik
