Fairly certain that once the query has reached a RESPONDING state TASM workload settings do not effect it. The duration which a query remains in RESPONDING state depends on environmental factors such as network bandwidth between TD and the client, whether the client application is prompting the user to return the full resultset (e.g. SQL Assistant), and the volume of data being returned to the client.
Something tells me that the query would not be parsed until after the workload has been released from the delay queue. Otherwiser, TD would have to keep the plan cached for the unknown duration in which the workload has been delayed. During the time which workload has been delayed there could be changes to the underlying tables that would adversely affect the plan.
Thanks Rob.
For the second question (Parsing), the explanation that you gave is what exactly ran through my mind but I was doubting since Teradata wouldnt want the 'syntax errored' queries to be kept in delayed queue. User will go mad if his query comes back after 20 mins (considering that the query stayed in the delay queue) throwing the SQL syntax error exception. Also, I see that the queries in delayed queue are already classified ( I can see the workloads tagged to those queries from the Viewpoint). Hence I am not sure whether the parsing is half baked before delaying the queries.
Hi All,
I've two questions: