The Dispatcher exercises execution and response control, and manages transaction and request aborts and the queue table cache.
The Dispatcher has four primary functions:
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.
Teradata Database 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 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.
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.
Transactions and requests can abort for several reasons, both normal and abnormal.
Typical normal aborts are caused by the following actions.
Typical abnormal aborts are caused by the following actions:
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.
See “CREATE TABLE (Queue Table Form)” in SQL Data Definition Language for more information about the queue table FIFO cache and its operation.