Marc, I don't think anybody would dislike this option to be available, but at the same time it seems that all your examples of why this would be useful are corner cases, and most people would rather have Timo work on other things. So, given that Timo is nothing more than a slave for the majority :) please stop arguing your case and go and make your solution to your problems. If it ends up being useful, I'm sure it can find its way into Dovecot's codebase.
One suggestion. Because you keep talking about how this is not about performance but about power, if I were you I'd stop focusing so much on mySQL, and look start looking at more powerful implementations of SQL.
On Wed, 7 Jun 2006, Marc Perkel wrote:
Les Mikesell wrote:
I think the people who expect an improvement from databases over maildir are used to unix filesystems that degrade badly as the number of files in a directory increase. These days many, like Reiserfs and XFS, are much better. My theory is that if your filesystem isn't a good place to store things you should fix that before thinking about databases.
Suppose you have a total of one million messages stored for 5000 users across 800 domains and you want to delete all message that were sent from a specific host. With MySQL it's a one line command and would take only a few seconds to execute. Using Maildir it would take hours because you would have to search every message. That's the power of MySQL.
Maildir only is fast for indexing file names. But if you are indexing across users and domains by host, or headers, or senders, or whatever then only a database can support these multiple indexes. There are things you can do with databases that are way beyond what you can imagine. Especially if you are integrating it with a spam system.
For example, a new message comes in and you find that sender matches email in 100 people's spam folders and none in any other folder? It can be classified as spam. If however the from address matches ham in people folder and no spam then you can probably deliver it without spam scanning.
This issue isn't performance, it's power. If you compare it with what people are doing now then MySQL would probably be a little slower. But if you compare it to what is possible that you can't do now then MySQL wins.