devdocs/specs/core-performance.txt

@@ -67,7 +67,7 @@ SELECT indexrelname,cast(idx_tup_read AS numeric) / idx_scan AS avg_tuples,idx_s
 
 WORK IN PROGRESS:
 
-Search result list:
+Search result list NAME FETCHER in :
 
 //Before attempt to optimize name fetcher (unknown number of results)
 //22548, 21187, 20462, 22336, 20094 - AVG = 21325
@@ -92,3 +92,13 @@ Now I'm going to try it with the index put back in and data regenerated
 Now fresh test but without index being crated
 ### 14244 results with index in place (after a restart of server, and bypassing EF entirely with a direct query OPTIMIZED TO REUSE CONNECTION): 14270 results - 13176, 12688, 13179, 12994, 12272 AVG: 12,861 = .90 per result
 
+index put back in and data regenerated
+### 14255 results with index in place (after a restart of server and bypassing EF entirely with a direct query OPTIMIZED TO REUSE CONNECTION): 12461, 12040, 11171, 11141, 11214 AVG: 11605 = .81 per result
+OK, this tells me that it's faster with the index in place and intuitively that just makes sense.
+Also verified it's actually using the index scan instead of table scan.
+I'm going to enact a policy to index id,name in all objects that have many columns, if they only have a name and id and not much else then there seems little benefit
+
+### results ("final" id,name indexes on user table and widget table, freshly generated data), 14202 RESULTS: 13295, 14502, 11774, 12521, 12101, 13169 AVG: 12,893 = 1.15
+
+Ok, it just makes logical sense to keep the indexes even if slightly slower, I can revisit this later, the difference is miniscule.  I suspect with a bigger database there would definitely be better peformance.
+