From kde-pim  Mon Dec 08 13:48:44 2014
From: Daniel =?ISO-8859-1?Q?Vr=E1til?= <dvratil () redhat ! com>
Date: Mon, 08 Dec 2014 13:48:44 +0000
To: kde-pim
Subject: Re: [Kde-pim] Excessive amount of queries
Message-Id: <1635209.Dnm4lff9Gy () thor>
X-MARC-Message: https://marc.info/?l=kde-pim&m=141804654614141
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--===============5767337575285794005=="


--===============5767337575285794005==
Content-Type: multipart/signed; boundary="nextPart18910682.oP3tVqsIrf"; micalg="pgp-sha1"; protocol="application/pgp-signature"


--nextPart18910682.oP3tVqsIrf
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"

On Monday 08 of December 2014 10:53:59 Milian Wolff wrote:
> On Friday 05 December 2014 18:50:14 Daniel Vr=E1til wrote:
> > The change has been pushed now, feel free to test :-)
>=20
> Nice work, seems to have helped a lot already! Some questions on the =
code:
>=20
> CollectionStatistics::getCollectionStatistics
> -> could that use CountQueryBuilder?
>=20
> CollectionStatistics::instance
> -> can we rely on proper static initialization instead, or is this co=
de run
> with compilers that don't implement this properly?
> -> at least, use QMutexLocker please

Well spotted, thanks.

I just pushed another batch of optimizations that reduce the query coun=
t even=20
further, most importantly opening an email in KMail now only does 5 que=
ries=20
instead of ~200 :-) There are 4 queries done by the FETCH command (SELE=
CT=20
PimItem, PartTable and FlagTable and UPDATE PimItem), the rest was=20
SearchHelper::listCollectionsRecursively invoked from SEARCH command (K=
Mail=20
searches for sender in addressbooks), which was recursively iterating t=
he=20
entire collection tree, doing one query per collection. I've optimized =
it, so=20
in the best case (searching in all collections) we only do one query, a=
nd in=20
the worst case we traverse the chain from each collection with matching=
=20
mimetype up to root (or first matching ancestor), which will still be m=
uch=20
fewer queries then previously.

According to your query aggregation view in Akonadi Console, the most-o=
ften=20
invoked queries now are those 4 or 5 queries from FetchHelper - there's=
=20
nothing we can do about those - we simply need to query the database fo=
r each=20
item. They represent about 95% of all executed queries (but only about =
50% of=20
overall query duration).

Second are 4 or so queries related to collection statistics and listing=
 of=20
collections, which together make about 2% of all queries (cca 25% of ti=
me)

I think at this point we are pretty good and I wouldn't bother with the=
=20
remaining queries much.

Dan

>=20
> bye

=2D-=20
Daniel Vr=E1til | 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
--nextPart18910682.oP3tVqsIrf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAABAgAGBQJUhaw+AAoJEMWdYU9vSuNIOJwH/2G/rw92rnzA/MKktHvdqWNX
NxsH4R2zP6F/7FFaE44Jr9JhtGwF+G18e5XxqJwYMnQy2e2dMSxuT2Z4iNeHhqlj
VrbKjuMNSaPF4SHRZFd6gL1Q1zZGTr6UCAaKn8sd/CtQPzygXejuFsTM3ELAUQBL
u+CayQS5fjx0GwQZsltPB8x3nnp+N7N1yeXaiw9Smqh8+/PbtJKZXcDtwbK5xUpY
0uBcICom4UKPlS6E91Dr8/Cw9AjLdr6rl3MhEFM5jxOkE8C6/a5XYGjEt2eSKast
QvbuXE5vfH8JKHn7twMszB0elS/hGUL54l9oA0t0NrOlLtCmRM1EPLcXZsSvNSg=
=1IQp
-----END PGP SIGNATURE-----

--nextPart18910682.oP3tVqsIrf--


--===============5767337575285794005==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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/
--===============5767337575285794005==--