Penalty Box Over-Population - comment by carrie

It's usually a good idea if you can identify poorly-written queries before they run and create filter rules in TASM to reject them before they begin to run.   I have seen such rules be very successful in preventing large unconstrained product joins from getting into the system.   However, aborting bad queries, once they have been identified is also a commonly used approach.
 
If you do not choose to abort a CPU-intensive query, then it may continue to consume a lot of CPU no matter which workload you move it to, even if that is a penalty box.  The only choice you have if you do not want that much CPU used by a query is to abort the query.
 
Are you saying that you use the explain estimates to classify queries, and that sometimes explain estimates cause a query to classify to a low priority workload, and then the user complains because the query takes a long time to complete?  If that is the case, it can indicate that you to collect better statitics, so the optimizer can produce more accurate estimates.  If there are certain queries that are always critical, you may not want to use estimates to classify them, if you estimates are inaccurate.
 
I cannot advise you when to abort a bad query or whether to abort at the request or the session level.  Those decisions are very site-specific and depend on what business needs you are trying to meet and the importance of the work involved.   But from what I have seen, many sites use CPU time and skew when they decide whether or not to abort a query.  You could post that question on the Teradata Forum where many people will have the opportunity to respond to you, and see if others can share example with you.   
 
Thanks, -Carrie