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

[Dmitry Torokhov]

On Tue, Nov 29, 2011 at 08:05:02PM +0100, Milian Wolff wrote:
> On Tuesday 29 November 2011 09:46:14 Dmitry Torokhov wrote:
> > Hi,
> > 
> > So I have upgraded from very usable setup with Fedota 15/KDE 4.6.x to
> > Fedora 16 with shiny new KDE 4.7.3 and brand new KDE PIM suite and as
> > many users found that the new version Akonadi/Kmail2 is pretty much
> > unusable. The conversion of my archive mailbox (mixed maildir) and 2
> > IMAP accounts ran for over 8 hours and I am not quite sure what state it
> > is in the moment as Kontact is trying to open my work mailbox for over
> > 10 minutes now (ever since I got to my desk and woke up my laptop).
> > 
> > Looking at the Akonadi mysql database I see that I have 3 large tables:
> > - parttable:			587230 rows;
> > - pimitemflagrelation:		241688 rows;
> > - pimitemtable:			294840 rows;
> 
> I just want to comment on this and leave the rest to the real pimpsters:
> 
> You say here that this is an outrageous amount of data and that it has to be 
> slow and what not. That is actually not true. This are just a couple of 
> thousand rows,

As I shown above, not a couple thoushands but couple _hundred_
thousands. Please test with real setups.

> something that MySQL should handle just fine.
> 
> Note that the KDEPim stack is continously being optimized and I severly doubt 
> that the KDE 4.7 version is even near the place where MySQL was the 
> bottleneck.

Again, I have shown that mysqld on my box took about 8 hours to process
my accounts, so for me it was the bottleneck as my laptop was unusable
for that long (and hardly usable now).

> 
> I understand how this experience is far from optimal, but refrain from 
> spreading such FUD as the above. I also have lots of problems with KMail2 but 
> I actually sit down and try to fix them. Which so far works out pretty well.

This is not FUD, this is my analysis and invitation to discuss the
issues many users are facing.

> 
> Another thing: If we ever come to the point where MySQL is the bottleneck, the 
> current architecture should make it rather simple to come up with an 
> alternative, optimized architecture. Personally, I just doubt that we are able 
> to design a relational database from scratch that will outperform MySQL so 
> easily...

Thet is the main question: do we really want a monolithic database here.

> 
> Bye
> 
> PS: If you want to help KDEPim constructively, build it from master (it is 
> much better there already compared to the 4.7 version) and profile it. Show us 
> data from callgrind, perf, systemtap, vtune, ... That way we can actually 
> improve it and don't have to waste time in a debate on principles.

No, I do not think I am wasting time here, sorry you have this
impression.

-- 
Dmitry
_______________________________________________
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/