Statistics Threshold Functionality 101 - comment by carrie

Sandeep,
 
I have not heard of any issues with UseCount logging overhead being problematic.  UseCount logging uses the same techniques as other DBQL collections.  There is a UseCount DBQL cache that is flushed at pre-set intervals and the cached entries are inserted into the database in a very efficient way.  However, every site is different, so cannot tell you for sure that you will not experience some overhead.  But based on feedback from other customers, it is not likely.
 
StatsUsage and XMLPlan logging, on the other hand, do come with some overhead.  For that reason, we recommend you only have that type of logging on for limited periods of time to capture representative queries when analysis is going to be performed.  StatsUsage has less impact as it is at the request level, while XMLPlan is at the step level and will have more overhead.
 
I can not think of any reason why 1000 rows in the DBQLRules table would be an issue.  These new options will cause the number of rows to increase, and I think that is expected.
 
In terms of AutoStats, a Collect job currently is limited to a single session.  However the collect lists generated by a Collect job group all the stats on a table into a single statement, so there will be parallelism and overlap achieved there.
 
If you have more available cycles you want to put into stats collection there is no reason you cannot create multiple Collect jobs with non-overlapping object scopes and schedule them to run at the same time.   Try to stay away from too many Collect jobs running at the same time, as that could become difficult to manage and monitor.
 
The AutoStats orange book (availabe in the orange book repository) has a lot of helpful tips in using AutoStats if you need more information in that area.
 
Thanks, -Carrie