Teradata Express Requests

Roland Wenzlofsky

August 10, 2015

minutes reading time

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 bypass 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 containing information about permissions.

When the Parsing Engine needs access to DBC to do its task, but the information is not cached, Teradata will send an express request to the AMP(s).
While express requests are usually fast and efficient, they may become problematic if the AMP runs 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, parsing 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 near zero or NULL (NULL means that Teradata cached all needed information in memory).

Teradata 14.10 offers a new feature to avoid such parsing delays:

Expedition of Teradata Express Requests

These new features (14.10) allow express requests to use the exact mechanism implemented for tactical workload:
Some AMP worker tasks are exclusively reserved for tactical workload queries on each AMP. They are from workload types of 08/09. Reserving AWTs allows executing tactical queries even in 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 being queued on the AMP.

Of course, if tactical queries and express requests share a common pool of AWTs, there is a particular concurrency situation. But as express requests are fast and efficient, this should not be a big issue.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

You might also like