[Kde-pim] Akonadi: single database design mistake?

[Martin Steigerwald]

Am Donnerstag, 1. Dezember 2011 schrieb Martin Steigerwald:
> I use KMail 1 from KDE 4.6.5 via IMAP to access my work mail as well,
> but  I learned that I better do not point it at that insane kernel-ml
> folder. Cause it seems that even with its flat index files it is not
> able to cope with it in any reasonable amount of time.

To be fair. That then is via IMAP. And I actually do not know whether the 
IMAP protocol was designed with mail folders with 250000+ mails in it in 
mind or whether either the server side or client side IMAP implementation 
could use some optimization. But still KMail 1 AFAIR also has local 
indexes for IMAP and it could at least start showing whats in there while 
doing the IMAP update in the background. Oh wait... KMail 2 with Akonadi 
could do this. KMail 1 was not designed for offloading that work to the 
background.

Accessing local maildir folder kernel-ml for my private mail account with 
KMail 1 almost instantly displays mails. But it takes quite some time to 
do the threading then and while this typing in there is really sluggish.

Accessing archival mboxes of kernel-ml, like 2010-1 here with about 113000 
mails, is almost instant as well. So for sure the index implementation of 
KMail 1 seems to do quite well.

But I see no reason why an Akonadi based KMail could not deliver similar 
performance.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/