No. Especially seeing your source sizes, you’re in at least what’s thought to be reasonable.
The database change with 2.0.7.1 was to add four indexes, making DB a bit bigger but also
maybe making the query slow temporarily until it had enough analysis information to do well.
One suspect is that the new indexes are somehow making the SQL query plan worse until
information is set up with one of the PRAGMA such as you did manually. If you get another
one that starts slow, it’d be nice if you could try doing logs view as mentioned which can be
done by less SQL-savvy people. SQLite site’s PRAGMA optimize documention sounds like
it’s intended to run analyze when it’s needed, and in your case it seems like it was needed.
Determination Of When To Run Analyze
One or more indexes of the table are currently unanalyzed
might have run if you’d done some light weight operation first. This wasn’t meant to happen.
was proven to help in at least some cases, but sometimes these things vary with the situation.
Somehow 2.0.7.1 managed to interact badly with Unraid FUSE in a similar slowdown found at
Backup Runtime after 2.0.7.1 update long thread, so linked to the happier conclusion, however
details of how things managed to get worse needed more investigation than could be provided.
If your system was still slow, I’d have asked for system performance info, e.g. is the disk busy?
SQLite can’t fill up all the CPU cores, but it’s very able to occupy a drive, especially a hard disk.
Typically you’d be able to spot sluggishness in some other thing you run live. Did you see any?