Suresh,
Could this be a PREPARE statement, if it is coming from ODBC.
Based on ODBC settings, queries will get submitted twice. The first time for parsing and second rime for actual execution. You can recognize Prepare queries because they have a WDID as NULL and AMPCPUTime with zero, but will have corresponding ParserCPUTime. Queries which represent the actual execution will have a non-NULL WDID and will show AMPCPUTime.
If the request doesn't go the AMPs (as evidenced by having NULL in WDID), then a throttle could not delay that request. Throttles are enforced at the dispatcher level before the first step in the request is sent to the AMPs, but requests with WDID of NULL never pass through the dispatcher module.
There is more information on this and the possibilites of unexpected delays on the blog posting called: Things That Run In Session Workload.
http://developer.teradata.com/blog/carrie/2015/11/things-that-run-in-the-session-workload
Thanks, -Carrie
Suresh,
Could this be a PREPARE statement, if it is coming from ODBC.
Based on ODBC settings, queries will get submitted twice. The first time for parsing and second rime for actual execution. You can recognize Prepare queries because they have a WDID as NULL and AMPCPUTime with zero, but will have corresponding ParserCPUTime. Queries which represent the actual execution will have a non-NULL WDID and will show AMPCPUTime.
If the request doesn't go the AMPs (as evidenced by having NULL in WDID), then a throttle could not delay that request. Throttles are enforced at the dispatcher level before the first step in the request is sent to the AMPs, but requests with WDID of NULL never pass through the dispatcher module.
There is more information on this and the possibilites of unexpected delays on the blog posting called: Things That Run In Session Workload.
http://developer.teradata.com/blog/carrie/2015/11/things-that-run-in-the-session-workload
Thanks, -Carrie