On Fri, Nov 30, 2007 at 01:16:25PM +0200, Timo Sirainen wrote:
On Fri, 2007-11-30 at 12:00 +0100, DINH Vi?t Ho? wrote:
On Nov 30, 2007 11:38 AM, Timo Sirainen tss@iki.fi wrote:
Zimbra is apparently building full text search indexes while appending, so this test doesn't mean much until I can test Dovecot's performance with Squat indexing.
Hello, in fact, I'm not that much convinced by full-text search index server side. We consider response time, server side full text search will include client-server round-trip. So that, for example, on etpanX, I do some local indexing on the imap folders, so that when the user does a search, it's given in a fraction of second even if the server is slow. I think Mail.app on Mac OS X is doing the same.
Yes, and so do many other clients. But FTS indexes are useful for webmails, mobile clients and other clients that don't have a local cache.
Squat indexes are going to work so that the first time you do a TEXT or BODY search the indexes are built for the mailbox. After that they most likely are updated when saving new mails (although maybe only with deliver, not with APPEND/COPY?). If user hasn't done any TEXT/BODY searches for a month or so, the indexes finally get deleted. Or that's my plan currently, those rules are easy to change.
I (and other users here) have some mail folder archives that go back several years and a number of those folders won't change, I what I was thinking of doing was do a full text search over ALL of the mail I can possibly access, so I will be all set for future fast searches, which might be of interest only once a year. I was thinking after we get dovecot into full production for at least half or a whole year, evaluating the space used by indexes of any type and make a site specific purge script if desired. It sounds like the indexes, if not automatically deleted, will be worth the more or less permanent disk space for us. Sounds like it would be useful as a configurable option.