What I meant is that analyze is run at the end only if >100 changed
tracks have accumulated since the last analyze.
So one could increase OPTIMIZE_THRESHOLD to reduce the number of times
analyze is run

Oh wow... don't know what I thought when I did that change: there's a "if main::SCANNER" with a comment that that optimization should only happen if NOT in the scanner. Quite contradictory... And there's an "if !main::SCANNER" around it anyway. So... this code is not even reached when run from the scanner process. The second condition (and the comment) are irrelevant.

Unless LMS is running the in-process scanner. In that case the condition imho is actually wrong and should be fixed...

In regular scans the "optimization" step consists of an ANALYZE followed by VACUUM (if using SQLite).

https://github.com/Logitech/slimserver/blob/public/7.9/Slim/Schema.pm#L414
https://github.com/Logitech/slimserver/blob/public/7.9/SQL/SQLite/schema_optimize.sql
https://github.com/Logitech/slimserver/blob/public/7.9/Slim/Utils/SQLiteHelper.pm#L324

--

Michael
_______________________________________________
beta mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/beta

Reply via email to