[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] Excessive amount of queries
From:       Daniel =?ISO-8859-1?Q?Vr=E1til?= <dvratil () redhat ! com>
Date:       2014-12-05 17:36:00
Message-ID: 3834197.NjFSeY4Xcy () thor
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Monday 01 of December 2014 12:29:39 Milian Wolff wrote:
> Hello all,
> 
> I know you are all thinking about Akonadi Next, but I'd love to see some
> work on improving the Akonadi we have now, and will have for quite some
> time.
> 
> When you enable the query debugger in akonadiconsole, you'll see that just
> switching to a different email in KMail, will easily end up triggering ~200
> queries. Can someone with more knowledge tell me if really all of that is
> required? I'm in the process of improving the query debugger interface, to
> aggregate information on queries. That should show us better which queries
> are triggered repeatedly and take a long time.

Hi,

I found one more weakspot today: the PartType cache was disabled. PartTypes 
are queried extremely often by name, but they have a problem that the "fully 
qualified name" is composited of namespace and name ("NS:NAME"), which are 
stored in separate columns. I added some special workaround for this into the 
XSL files and now we now longer have to query PartTypeTable, as all calls now 
hit the cache (except for the first time of course).

This seems to have reduced the amount of queries massively, especially during 
sync and fetch.

Dan

> 
> Bye

-- 
Daniel Vrátil | dvratil@redhat.com | dvratil on #kde-devel, #kontact, #akonadi
Software Engineer - KDE Desktop Team, Red Hat Inc.

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
["signature.asc" (application/pgp-signature)]

_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

[prev in list] [next in list] [prev in thread] [next in thread]