15.10 - OptApply - Teradata Database

Teradata Database SQL Request and Transaction Processing

Teradata Database
Programming Reference
User Guide

OptApply produces concrete steps by placing data from a USING Data parcel set in a parameterized PK request (see “Data Parcel Peeking Terminology” on page 29), if present, into the plastic steps. Concrete steps are passed to the Dispatcher, which then distributes them to the AMPs via the BYNET.

Like the Generator, OptApply is actually a component of the Optimizer, but it is treated separately to facilitate explaining its function.

For other parameterized requests, the Parameterized Value Peek subsystem places USING data into the parse tree prior to the Query Rewrite/Optimizer phases of request processing. See “Peeking at Parameterized Values in the Data Parcel” on page 28 for details.

The following diagram illustrates OptApply activity.

The OptApply component of the Parser engages in the following processing stages:

1 OptApply receives the plastic steps for a request from the request cache or from the Generator.

2 The plastic steps are compiled into executable machine code.

3 OptApply retrieves any parameterized PK request Data parcels associated with the Request parcel and applies them to the plastic steps, creating concrete steps.

Concrete steps are also referred to as AMP steps.

For any simple data‑driven iterative insert request, the system optimizes the operation by processing multiple insert operations in a single AMP step.

Note that the system performs this optimization only for simple iterated insert requests.

4 The concrete steps are sent to the Dispatcher, which sends them across the BYNET to the AMPs.

Concrete steps are context- and data-laden AMP directives that contain user- and session‑specific information in addition to Data parcels.

Each concrete step is composed of four parts:




System message header

Contains the message class and kind, length, logical host identifier, session and request number, version number, and character set code.

Common step header

Contains account numbers and routing information.

Specifies who is to receive the step, what should be done with the responses generated by the step, how the AMPs signal task completion, and what is the context for the step (for example, a transaction number).

Step components

A series of operation-dependent fields including step flags and the step mode.


Contained in a varying length data area.