devdocs/todo.txt

@@ -27,7 +27,14 @@ Once that is done then can steam ahead on the biz objects but until I have the c
 
 IMMEDIATE ITEMS:
 ================
-
+Current huge seeding takes around 15 minutes
+Current unbounded search for "et*" in huge dataset takes avg 21 seconds to process 
+{
+  "phrase": "et*",
+  "nameOnly": false,
+  "typeOnly": 0,
+  "maxResults": 0
+}
 
 	- Search and search text indexing		
 	- https://gist.github.com/ruckus/5718112			
@@ -35,22 +42,12 @@ IMMEDIATE ITEMS:
 		- Can it be sped up with the huge dataset test
 		(The actual slowness is directly related to namefetch so that's where I am concentrating effort)
 		
-			- First up is to test generate data again and see if the name fetcher query uses the compound name/id index I added when data is generated freshly
-				- First add to ayschema these two indexes (2 in case one preferred over other or order issues)
-	
-	CREATE INDEX widget_idx_test_name_id2
-    ON public.awidget USING btree
-    (name COLLATE pg_catalog."default", id)
-    TABLESPACE pg_default;
-	
-				CREATE UNIQUE INDEX widget_idx_name_id
-    ON public.awidget USING btree
-    (id, name COLLATE pg_catalog."default")
-    TABLESPACE pg_default;
-
-
-			
-		
+		- One final test *WITH* the index again just to confirm the earlier results, if it's confirmed slower then remove the index 
+		 but keep the code in place in case it becomes faster again with it later
+		- Re-run the integration tests for search performance and set a new benchmark minimum for that shit as it should be way faster now				
+		- Change return object from a search to include a count of results plus the restricted list of results	
+			- this way the Client can know there are tons more than just weren't shown so they can narrow their terms
+		- 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)