Elevating Parsing Priority - comment by geethareddy

hi Carrie,

Is there any limit on number account strings that need to be created for one system. Currently we have one for individual user and databse (except, for DBA's Developer's, and some system oriented id's).
For ex: If we have an application, we create 7 different objects and 7 different account strings, like
ASE1 for AppID-Application id for that application),
ASE2 for UserID-user id for that app,
ASE3 for View DB ID,
ASE4 for Logical View DB ID
ASE5 for MartTabl DB ID...ASE6, ASE7...like this each application gets 7 different account strings. (I used some random example).
But like this our list of ASE are increased to 3 digit number (800+ different account strings) and going to reach the 4 digits number shortly. So is there any limit is my first question.
And my 2nd question is.. I am concerned about 99% of them (800 + account strings) are mapped to MEDIUM Performance Group(PG), and i know we need to tweak them to allocate some of the low level applications and User IDs to LOW priority PG ($L). And important ones to HIGH (but not to RUSH, i heard R is for internal tasks, please correct me if i am wrong). Here i just wanted to know are there any best practies need to be followed to keep the number low for number of accnt strings and better way to map the existing and future account strings to L/M/H PGs(or may be create more PGs for better maintenance).
 
 
Thank you,
Geeta.