15.10 - Generator - Teradata Database

Teradata Database SQL Request and Transaction Processing

Teradata Database
Programming Reference
User Guide

The Generator formulates the AMP processing steps, called plastic steps, based on the optimized parse tree plan it receives as the output of the Optimizer. The plastic and concrete steps generators are actually components of the Optimizer, but are treated separately to facilitate explaining their function.

Except for any hard‑coded literal values that may be used, the plastic steps do not have any data values associated with them.

A single request parcel can generate many plastic steps.

The following block diagram illustrates the workings of the Generator. The Generator is also the home of the Teradata Database hashing algorithm.

1 The Generator receives the optimized parse tree from the Optimizer and uses it to build plastic steps.

2 Each step is created with a step header containing fixed information about the step and the component of the step, which is the actual context-free AMP directive.

3 Depending on the nature of the request, one of the following outcomes occurs:


IF the plastic steps were generated as the result of …

THEN they are sent to …

a data-containing request parcel

1 the request cache.

2 OptApply and dispatched across the BYNET to the AMPs.

an EXPLAIN modifier request

the user in the form of a report on steps taken and the projected speed of their execution.

The Generator creates a series of optimized directives for the AMPs that contain column and row information, but no literal data values. These steps, called plastic steps, are later transformed into concrete steps by OptApply (see “Definition of Concrete Steps” on page 68). Plastic steps allow sets of values taken from the USING request modifier in parameterized‑independent requests to be inserted into the optimized query plan during subsequent Parser operations.

The Generator writes the plastic steps into the request cache, then sends them to OptApply. The plastic steps contain all the context-free information there is to know about a request and so are cached for potential reuse.

Parser logic assumes that requests with USING request modifiers are submitted repeatedly, though with different data, and benefit from reusing the plastic steps.