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
We need a fresh feedback using a recent digiKam release as last 4.2.0.
With digikam 4.2., windows, the query is no longer reported as slow (>1s) query. So I suggest to close this bug.