The Dispatcher
The Dispatcher exercises execution and response control for requests and dynamic plan fragments, and manages transaction and request aborts and the queue table cache.
- Apply TASM rules and classify into workload.
- Route AMP steps to the appropriate AMPs.
- Return result or statistics feedback to the optimizer so it can generate the next plan fragment when executing a dynamic plan.
- Return the results of a request to the user application that submitted that request.
- Notify client applications and Teradata platform processors of aborted transactions and requests.
Execution Control
Execution control is the term applied to Dispatcher handling of concrete steps.
The Dispatcher routes the concrete steps in the plan for a request to the appropriate AMPs for processing. Once a concrete step has been placed on the BYNET, it is referred to as an AMP step.
Part of the routing function of the Dispatcher is the sequencing of step execution. A new step is never dispatched until the previous step has completed its work, which is signalled by a completion response from the affected AMPs.
Vantage can dispatch a parallel step if the previous step has finished acquiring its task locks, but has not yet completed its work. This is signalled by a response from the affected AMPs, and the Dispatcher determines that it can send another parallel step.
Depending on the nature of the request, an AMP step might be sent to one, several, or all AMPs (termed point-to-point, multicast, and broadcast, respectively).
Execution control also monitors the status reports of individual AMPs as they process the steps the Dispatcher has sent to them and forwards the results to the response control function once the AMPs complete processing each step.
Response Control
Response control is the term applied to Dispatcher handling of results. The second most important function of the Dispatcher is to return the (possibly converted) results of a request to the requesting application.
Transaction and Request Abort Management
The Dispatcher monitors transactions for deadlocks. When a deadlock occurs, the Dispatcher resolves it by managing the locked resources consistently and resolving the deadlock in the most optimal manner available. This often means that one of a pair of deadlocked transactions must be aborted.
The Dispatcher process request and transaction aborts by notifying both the client application and all affected Teradata platform virtual processors.
- TDP logoff command
- Client application terminates normally
- Syntax and semantic errors in a request
- Internal Parser errors such as memory overflow
- Internal AMP errors such as primary index conflicts
- Transaction deadlocks
Queue Table FIFO Cache Management
The Dispatcher maintains a cache that holds row information for a number of non-consumed rows for each queue table. The system creates this queue table cache during system startup. There can be a queue table cache task on each PE in your system.
The queue table FIFO cache row entries on a given PE are shared by all queue tables that hash to that PE. Each queue table row entry is a pair of QITS and rowID values for each row to be consumed from the queue, sorted in QITS value order.
During startup, the system allocates 64KB to the queue table cache on each PE and increases its size dynamically in 64KB increments to a maximum of 1MB per PE as required. The system initializes all the fields in the cache during startup and allocates space for 100 table entries. As queue tables are activated, they populate these slots beginning with the lowest numbered slot and proceeding upward from there. When the maximum cache size is reached, the system flushes it, either partially or entirely, depending on the number of bytes that must be inserted into the cache.
For more information about the queue table FIFO cache and its operation, see the CREATE TABLE (Queue Table Form) command in Teradata Vantage™ - SQL Data Definition Language Syntax and Examples, B035-1144.