reopen 591298 notfixed 591298 3.7.0-1.1 found 591298 3.7.2-1 thanks
Hello again, On Fri, Aug 27, 2010 at 10:02:54AM +0100, Will Thompson wrote:
Hi Ondřej, [...] With the CoreCache parts of the query removed, it's very snappy: % time sqlite3 banshee.db.copy < banshee-init-core-cache.sql < banshee-next-shuffle-by-album-no-core-cache.sql 4478|Heartland|1282844295|1277228957 sqlite3 banshee.db.copy < banshee-init-core-cache.sql < 0.22s user 0.04s system 97% cpu 0.267 total But in its original form, it's reliably a hundred times slower, taking over 22s: % time sqlite3 banshee.db.copy < banshee-init-core-cache.sql < banshee-next-shuffle-by-album.sql 1063|Stars On The Wall|1282654498|1272661309 sqlite3 banshee.db.copy < banshee-init-core-cache.sql < 22.28s user 0.07s system 99% cpu 22.377 total It's equally slow if I make CoreCache a regular table. I've checked Banshee's Git history briefly, and can't find any changes relating to CoreCache that could have caused this. I wondered if some indexes have been binned or something. But, if I downgrade to libsqlite3-0 3.6.23.1-4 the slower query is miraculously fast again: % time sqlite3 banshee.db.copy < banshee-init-core-cache.sql < banshee-next-shuffle-by-album.sql 550|Happy Songs for Happy People|1280848000|1280848242 sqlite3 banshee.db.copy < banshee-init-core-cache.sql < 0.27s user 0.03s system 99% cpu 0.302 total I've uploaded my Banshee database, plus the three SQL scripts used, to http://willthompson.co.uk/misc/banshee-sqlite-bug-591298 in the hope that they'll be useful.
Thanks for your analysis. I've just looked at upstream's mailing list, and it doesn't look like this has been discussed there. Would you be able to forward this problem to them[0] quickly? Don't bother signing up; I found the moderation to be reasonably quick. If you have no time, just let me know and I'll do it for you. :) Cheers, Iain [0] sqlite-us...@sqlite.org
signature.asc
Description: Digital signature
