on startup, the following sql is executed serveral times, which costs ~5 sec each. -- SELECT creationDate FROM ImageInformation INNER JOIN Images ON Images.id=ImageInformation.imageid WHERE Images.status=1; -- also, when I import pictures, this sql is executed for every imported picture (5sec each!). I just wonder, why the creation datefor all pictures (80.000 in thi collection) is neccesary that much. Since this costs my lots of time, please have a look at this. For your information: the sql itselve is very fast, but fetching the 80.000 creationDates costs the 5 sec,even when I fetch them on the server (synology DS213+).
Created attachment 82096 [details] log from mysqld-slow.log with queries longer one sec, while importing images
So you have the MySQL on a NAS server and the network is the bottleneck? The query is done to update the timeline view, and is usually relatively fast. There is a timer defined in AlbumManager that limits this scan to be done not more frequently than every 5 sec. Unfortunately, as it takes 5 secs for you, this is ineffective.
Git commit 145b25c573164111b75c1a8586b5aea50656572c by Marcel Wiesweg. Committed on 03/09/2013 at 20:08. Pushed by mwiesweg into branch 'master'. The DAlbums scan can be costly for some setup as it sends large amounts of data over the SQL connection. - reduce the timer limit to one minute - do not kill the running job if the timer fired again while the job was running. M +13 -2 digikam/album/albummanager.cpp M +1 -0 digikam/album/albummanager.h http://commits.kde.org/digikam/145b25c573164111b75c1a8586b5aea50656572c
We need a fresh feedback using a recent digiKam release as last 4.2.0. Gilles Caulier
With digikam 4.2., windows, the query is no longer reported as slow (>1s) query. So I suggest to close this bug. Rainer