Expediting Express Requests - comment by carrie

A change to the EnableExpReq does not require a restart.
 
You don't "throw a workload  at it" because the EnableExpReq setting is applied universally, it is not targeted to individual workloads.  Once set to 1, then all parsing for all queries will have their express requests expedited (assuming you have made the tactical reserve pool to be at least 2).
 
The only way to guage the effectiveness of such a change is to compare the values in the DBQLogTbl field ParserExpReq before the change and after, and see if it the values for the same or similar queries have gone down during times when AWTs are exhausted.  As I said before, changing this setting will not have any impact on how long express requests run unless the system is out of AWTs and express requests have been waiting to get an AWT.   So if you do a before and after comparison of the ParserExpReq field, it has to be based on the "before" time being at a time when the system was out of AWTs and the "after" time being at a time when the system was similarly out of AWTs.  
 
A precise comparison will not be possible because it is unlikely that the before and after situations will be the same (same number of AMPs out of AWTs, same number of AMPs experiencing flow control, etc.).  In addition, express requests are not issued at all if the data dictionary information is in the dictionary cache, so at different times the same query may report different values in ParserExpReq solely because of dictionary caching, or non-caching.   The best you can hope for is that you will see some overall reduction in the time it takes for a group of queries to execute express requests during times of congestion.
 
Just a reminder that because EnableExpReq is an internal DBS Control setting, it is best to contact the support center or CS and ask for their advice and assistance in making changes to this setting.   It is intended that changes to Internal DBS Control settings be managed by Teradata personnel.
 
Thanks, -Carrie