Teradata Express Requests
Express requests are sent to the AMP by the Parsing Engine each time it needs access to data dictionary information from the DBC database which is not cached in memory.
While user requests (such as SQL queries you are running) have to pass several stages in the Parsing Engine (resolving, syntax checking, permission checking, optimization), express requests are bypassing all these steps.
Instructions for express requests go directly to the AMP, as they are created and issued by the RDBMS, and therefore it’s not needed, for example, to do syntax or permission checking.
Many of the Parsing Engine modules can issue express requests:
- The Optimizer will require access to statistics information.
- The Resolver will need to access DBC tables holding information about located objects.
- The module checking permissions will need to access the DBC tables holding information about permissions.
Each time the Parsing Engine needs access to DBC to do its task but the information is not cached, an express request will be sent to the AMP(s).
While express requests are usually fast and efficient, they may become problematic if the AMP is running out of AMP worker tasks. If this happens, express requests are queued like all other tasks in the AMP’s queue (workload type 01 or “continued work”).
Without AMP worker tasks, the parsing of your query (or what PE module is missing) is delayed until AMP worker tasks are free.
You can quickly analyze such situations by checking the column ParserExpReq from DBC.DBQLOGTBL. High numbers are the indication of “out of AMP-worker-task” situations.
On a balanced system, this column will be most times near to zero or NULL (NULL means, that all needed information was cached in memory).
Teradata 14.10 offers a new feature to avoid such parsing delays:
Expedition of Teradata Express Requests
This new features (14.10) allows express requests to use the same mechanism which is implemented for tactical workload:
On each AMP some AMP worker tasks are exclusively reserved for tactical workload queries, they are from workload types 08/09. Reserving AWTs allows executing tactical queries even in the case of a very loaded system as these AWTs will be available (if not entirely occupied by other tactical workloads of course).
Since Teradata 14.10, the same pool of reserved tactical workload AWTs can be used by the express requests, avoiding to be queued on the AMP.
Of course, if tactical queries and express requests are sharing a common pool of AWTs, there is a particular situation of concurrency. But as express requests are fast and efficient by nature, this should not be a big issue at all.