devdocs/specs/core-performance.txt

@@ -1,5 +1,10 @@
 PERFORMANCE SPECS AND USEFUL INFO
 
+//this is handy:
+http://okigiveup.net/what-postgresql-tells-you-about-its-performance/
+
+
+
 Useful queries to indicate how indexes are being used in postgresql
 
 This is a test query I used with widget and name fetching performance analysis:
@@ -16,19 +21,21 @@ select * from pg_stat_user_indexes
 Reveals Unused indices
 =-=-=-=-=-=-=-=-=-=-=-
 
-SELECT 
-    relid::regclass AS table, 
-    indexrelid::regclass AS index, 
-    pg_size_pretty(pg_relation_size(indexrelid::regclass)) AS index_size, 
-    idx_tup_read, 
-    idx_tup_fetch, 
-    idx_scan
-FROM 
-    pg_stat_user_indexes 
-    JOIN pg_index USING (indexrelid) 
-WHERE 
-    idx_scan > 0 
-    AND indisunique IS FALSE
+SELECT * FROM pg_stat_user_indexes order by idx_scan asc
+
+ The basic technique is to look at pg_stat_user_indexes and look for ones where idx_scan, 
+ the count of how many times that index has been used to answer queries, is zero, or at least very low. 
+
+
+
+Detecting missing indexes
+=-=-=-=-=-=-=-=-=-=-=-=-=
+SELECT   relname, seq_scan, seq_tup_read, 
+      idx_scan, idx_tup_fetch, 
+      seq_tup_read / seq_scan 
+  FROM   pg_stat_user_tables 
+  WHERE   seq_scan > 0 
+  ORDER BY seq_tup_read DESC;
 
 
 Shows info on all indices
@@ -103,4 +110,34 @@ I'm going to enact a policy to index id,name in all objects that have many colum
 
 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.
 
-=-=-=-=-=-=-=-=-=-=-=-=-
+=-=-=-=-=-=-=-=-=-=-=-=-
+LOCALE ITEM
+b4 running multiple subset fetches
+
+256287	256301	"public"	"alocaleitem"	"alocaleitem_localeid_key_idx"	"2350"	"13667"	"5172"
+256287	256302	"public"	"alocaleitem"	"alocaleitem_localeid_key_display_idx"	"2618"	"2618"	"2618"
+256287	256294	"public"	"alocaleitem"	"alocaleitem_pkey"	"7085"	"7090"	"7085"
+
+"alocaleitem"	"24"	"133010"	"12053"	"14875"	"5542"
+
+after I run a bunch of fetch subset test over and over:
+256287	256301	"public"	"alocaleitem"	"alocaleitem_localeid_key_idx"	"2398"	"13715"	"5220"
+256287	256302	"public"	"alocaleitem"	"alocaleitem_localeid_key_display_idx"	"2618"	"2618"	"2618"
+256287	256294	"public"	"alocaleitem"	"alocaleitem_pkey"	"7085"	"7090"	"7085"
+
+                        seq_tup_read
+"alocaleitem"	"24"	"133010"	"12073"	"14895"	"5542"
+
+more
+
+"alocaleitem"	"24"	"133010"	"12141"	"14963"	"5542"
+
+256287	256301	"public"	"alocaleitem"	"alocaleitem_localeid_key_idx"	"2438"	"13755"	"5260"
+256287	256302	"public"	"alocaleitem"	"alocaleitem_localeid_key_display_idx"	"2618"	"2618"	"2618"
+256287	256294	"public"	"alocaleitem"	"alocaleitem_pkey"	"7085"	"7090"	"7085"
+
+Fresh regen, removed alocaleitem_localeid_key_idx kept alocaleitem_localeid_key_display_idx
+Before any test runs fetching subsets:
+256514	256521	"public"	"alocaleitem"	"alocaleitem_pkey"	"0"	"0"	"0"
+256514	256528	"public"	"alocaleitem"	"alocaleitem_localeid_key_display_idx"	"1667"	"1667"	"1667"
+