diff --git a/devdocs/specs/core-performance.txt b/devdocs/specs/core-performance.txt
index 287c782b..e9aa84a8 100644
--- a/devdocs/specs/core-performance.txt
+++ b/devdocs/specs/core-performance.txt
@@ -6,6 +6,15 @@ http://okigiveup.net/what-postgresql-tells-you-about-its-performance/
 
 
 Useful queries to indicate how indexes are being used in postgresql
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
+
+OK: this is the best query to use to find non used indexes
+Run it and look for any indexes that are *not* primary keys (name ends in pkey, want ones that end in idx which are mine)
+that have zero in idx_scan, that means they are completely unused (if a lot of full test runs that excercise all routes and features have happened prior to checking)
+
+SELECT * FROM pg_stat_user_indexes order by idx_scan asc
+
+Following queries might be useful but for different purposes...
 
 This is a test query I used with widget and name fetching performance analysis:
 explain analyze SELECT m.name
diff --git a/devdocs/todo.txt b/devdocs/todo.txt
index 9f4da59a..98768361 100644
--- a/devdocs/todo.txt
+++ b/devdocs/todo.txt
@@ -28,10 +28,7 @@ Once that is done then can steam ahead on the biz objects but until I have the c
 IMMEDIATE ITEMS:
 ================
 
-	- Schema: clean up all the LOOKAT items and verify the indexes are being used
-		- Run many tests then run this query: SELECT * FROM pg_stat_user_indexes order by idx_scan asc
-		- Look for any items that are not a primary key (name ends in _idx) and show zero idx_scan's, those are redundant
-			- The rest is Greek to me and not in a good way.
+	
 	
 	- 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, 
@@ -57,6 +54,11 @@ IMMEDIATE ITEMS:
 		- Shouldn't that shit log only to text file??
 		- Does it matter even though?
 
+	- LOGIN logging, seems like too much, maybe drop it down a level into a diagnostic level?  Or an option to be turned on? 
+		THIS: 2018-10-04 11:50:29.8943|INFO|AyaNova.Api.Controllers.AuthController|User number "7" logged in from "::ffff:127.0.0.xxx" ok
+
+	- Before moving on with api completely: Create a batch file to run integration tests in a loop and make it run overnight to see what shakes out at the server in terms of errors etc.
+
 Ensure all modern best practice security is properly enabled on helloayanova.com so testing is valid
 	- https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security#Deployment_best_practices
 
diff --git a/server/AyaNova/Startup.cs b/server/AyaNova/Startup.cs
index 113523b7..0e131fea 100644
--- a/server/AyaNova/Startup.cs
+++ b/server/AyaNova/Startup.cs
@@ -363,7 +363,7 @@ namespace AyaNova
             // ******************** TESTING WIPE DB *****************************
             //
             //Set this to true to wipe the db and reinstall a trial license and re-seed the data
-            var TESTING_REFRESH_DB = true;
+            var TESTING_REFRESH_DB = false;
 
 #if (DEBUG)
             //TESTING
@@ -405,7 +405,7 @@ namespace AyaNova
             if (TESTING_REFRESH_DB)
             {
                 AyaNova.Core.License.Fetch(apiServerState, dbContext, _log);                
-                Util.Seeder.SeedDatabase(Util.Seeder.SeedLevel.SmallOneManShopTrialDataSet);
+                Util.Seeder.SeedDatabase(Util.Seeder.SeedLevel.HugeForLoadTest);
             }
             //TESTING
 #endif