Understanding Teradata Express Requests and How They Work with AMPs
Learn how express requests work in Teradata, bypassing stages like syntax checking and permission checking, and how Teradata 14.10 offers a new feature to expedite them.
The Parsing Engine sends express requests to the AMP for data dictionary information from the DBC database that is not cached in memory.
Express requests avoid the multiple stages of the Parsing Engine, including resolving, syntax checking, permission checking, and optimization, that are required for user requests, such as SQL queries.
Express requests are directed straight to the AMP, which the RDBMS generates and distributes. This means that syntax and permission checks are unnecessary. Numerous Parsing Engine modules have the ability to produce express requests.
Want more practical data engineering analysis like this?
Join DWHPro Letters and get field-tested notes on Teradata, Snowflake, AI, migrations, performance, and enterprise data work. Early subscribers keep launch access before the paid plan launches.
- 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 containing information about permissions.
If the Parsing Engine requires access to the DBC and is not cached, Teradata will send an express request to the AMP(s). However, express requests can be troublesome if the AMP lacks worker tasks. At this point, they will be queued like other tasks in the AMP's queue under workload type 01 or "continued work."
Get the next issue by email.
Delays in parsing your query, or identifying missing PE modules, occur when AMP worker tasks are unavailable. This can be avoided by ensuring sufficient AMP worker tasks are available.
Analyze situations efficiently by reviewing the ParserExpReq column in DBC.DBQLOGTBL. Elevated figures suggest issues with AMP worker tasks.
In a well-adjusted system, this column should register as close to zero or NULL (indicating that Teradata has cached all essential information in memory).
Expediting Teradata Express Requests
The 14.10 update incorporates new functionalities that enable express requests to utilize the same mechanism employed for tactical workloads. On each AMP, certain worker tasks are reserved solely for workload types 08/09 associated with tactical queries. Reserving AWTs makes it possible to execute tactical queries even in a heavily loaded system, as these AWTs will be available unless fully occupied by other tactical workloads.
Starting from Teradata 14.10, the express requests can utilize the identical pool of reserved tactical workload AWTs, preventing queuing on the AMP.
Combining tactical queries and express requests into a shared pool of AWTs creates a specific concurrency scenario. However, considering express requests' rapid and effective nature, this should not pose a significant problem.
Planning or surviving an enterprise data platform migration?
I write regularly about the performance, cost, architecture, and project mistakes that show up in real Teradata, Snowflake, Databricks, and enterprise data work.
Subscribe before the paid plan launches and keep launch access.
Written by Roland Wenzlofsky, founder of DWHPro and author of Teradata Query Performance Tuning. DWHPro has helped data warehouse practitioners for 15+ years.