Thanks guys! There's definitely a pattern in what indices are useful and
which not... IMHO about half of them are questionable for one of a few
reasons:
- indexed column is not used (populated or accessed) at all (eg. track.hash)
- indexed column is not used in any search/sort task where the index
would be used (eg. trackSearchIndex: we only do "like" conditions)
- there are only very few different key values in a column used by the
index (eg. disc count)
- index is only used by some plugin - which could take care of creating
the index itself when it's installed (*CustomSearchIndex)
- index would only be used in cases where very few items would need to
be sorted (eg. albumsDiscIndex)
Some of the above reasons can be ignored if you use the advanced search
to eg. only play the first disc of a disc set across all albums you have
without any other condition :-).
I'll review that list and will most likely drop some or most of those
indices I consider irrelevant. While I didn't see much of an advantage
at scan time, I did see cases where loading an index to sort a hand full
of tracks (out of a hundred thousand) accounted for 90% of the whole
time spent on the query. If we can get rid of useless indices, we might
be able to get better performance with less memory used, as the memory
available would be consumed by useful data.
--
Michael
_______________________________________________
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/beta
