> > 1) It would be nice to provide multiple index sets - most of > > the ones that have been posted are good for imap, but almost > > entireley extra overhead if you just use pop3. We've improved > > our pop3 performance by removing most of them and perhaps > > optimizing a couple (or they may be identical, I don't remember).
Having said that, I think it was dbmail-smtp performance we improved by removing those indexes (ie. because the database doesn't have as many indexes to maintain). I think we did do some optimizing for pop3 too, though, but I don't know that it (ie. having the imap indexes or not) was as noticable there. > > It'd be nice to list a set that are good for pop3-only sites, > > imap-only sites, and sites with both services. And of course > > we'll throw in a set of recommended indexes for running weDBmail. ;) > I agree this would be nice. I'm not a database guru myself. Learning > though :) > I'm wondering how big the actual overhead is when using "IMAP"-indexing > with POP. Any ideas? Not really. Benchmarking is not one of our strong points. :) The best benchmark we use to judge the effectiveness of changes is when complaints stop - I don't think there were any complaints for this, it was more in the system build phase, trying to get things as good as they could be. > > 2) Please read the first paragraph of this message: > > http://twister.fastxs.net/pipermail/dbmail-dev/2003-June/000163.html > > That really ought to be done (ie. use only status flag to mark a > > message that is being inserted, and drop unique_id out of the > > indexes completely (well, except for the one index that is supposed > > to be for that field)). I was planning on working on it, but kind > > of ran out of time. > I like the idea of using the status field for this. We have to take > a careful look at all code to see if this does not have any > bad implications (I wouldn't know really). > > I'm really busy with all kinds of stuff now (including a lot of > DBMail work). Could you try to take a closer look at this. If it > turns out to be useful and working we will gladly accept a patch > for DBMail 2.0 implementing this. Realistically, probably not for a while (after November especially). I don't know how much of a difference this will make in performance, I would guess it depends on how the rdbms impliments indexes. If you had eg. 300MB ram used for indexes and could drop that in half, I can only guess it would be a Good Thing(tm). :) But I don't even know if indexes are kept in ram, or just on disk. -- Jesse Norell jesse (at) kci.net
