Reply to thread

Message: <blockquote data-quote="MJGraf" data-source="post: 1028313" data-attributes="member: 17886">Thanks for your comments Morph.I will do that in my synthetic Read Test 1 first, because there I can easily take out those aspects from the optional aspects.We have to keep in mind, however, in particular two things:<ul> <li data-xf-list-type="ul">most likely (if not certainly) the queries will be faster without these aspects to be queried. But what we don't know is how long it would take to read the (in this case 235) image files from disk. Although my first thought was that 300ms is quite heavy for single search in the database, I changed my mind a bit when I did the following calculation: My database is about 1.7GB in size holding about 20k media items. this means about 90KB per media item in average. At least 89 of these 90KB are for the cover picture. This means that if we store the covers as files in the file system instead of the database, we would have to read 235 files with about 89KB size each, i.e. we read in total 20.5MB from disk just for the covers. As per <a href="http://www.anandtech.com/show/3812/the-ssd-diaries-crucials-realssd-c300/2" target="_blank">this</a>, my SSD can do about 275MB/sec sequential reads and about 83MB/sec 4k random reads. With our 235 files of about 89KB we are most likely somwhere in between those two values, say about 150MB/sec. As a result, it would already take about 140ms to read these covers from files under ideal conditions (meaning those SSD performance tests usually don't work on a file system basis but on a very low level disk access basis to result in higher values. We on the other hand have to take into account the file system overhead). So 300ms for executing 12 SQL queries AND reading those 235 files from the database is not really that bad...</li> <li data-xf-list-type="ul">When I do the searches without the covers (i.e. no ThmubnailAspects in the optional aspects), the covers are still in the database. So the results I will get are not really what you would get if the covers were not in the database at all. For that I would probably have to comment the respective lines out in the AudioMetadataExtractor. Let's see if I find the time to do so over the weekend...</li> </ul>Anyway, I will try without fetching covers and report back. Will definitely have a look at MIA_Management to find out why this does not happen automatically. If it really doesn't create indices on foreign keys automatically, we should definitely include this as standard in our MIA_Management...</blockquote>

Verification