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.
+

devdocs/todo.txt

@@ -50,6 +50,7 @@ Current unbounded search for "et*" in huge dataset takes avg 21 seconds to proce
 		- see if any other callers to name fetcher are in tight loops and could benefit from using the new Direct version
 		- Update all the other routes to include search indexing (attachments, tags etc, anything with text in it)
 
+	- Schema: clean up all the LOOKAT items and verify the indexes are being used
 	
 	- EventLogProcessor.AddEntry: CHANGE this to save the context itself and then change all callers to handle that (remove save)
 		- I originally didn't have the save in there because I thought subsequent code might all share in the single context save,