|PE Software Components|
|Parser (Including Optimizer)||Session Control|
|PDE (Parallel Database Extension)|
Parser - Decomposes the SQL into relational data management processing
Dispatcher - Receives the processing steps from the Parser and sends them to the appropriate AMPs.
Session Control - Provides user session management such as establishing and terminating sessions.
The Parsing Engine is the virtual processor that communicates with the client system on one side and with the AMPs (via the BYNET) on the other side.
Each PE executes the database software that manages sessions, decomposes SQL statements into parallel steps, and returns the answer rows to the requesting client.
There are a maximum number of 16,384 virtual processors that can be supported on a single system (numbered 0 - 16,383). The PE vproc number ranges from 15,360 - 16,383.
The configuration utility in the AWS controls adding, modifying, and deleting PEs. When adding or modifying a PE, the PE number and HOST number are identified. Example: add PE 16344 - 16351, hn = 282
|1||The Parser looks in the Request cache to determine if the
request is already there.|
|2||The Syntaxer checks the syntax of an incoming request|
|The Resolver adds information from the Data Dictionary cache to convert database, table, view, and macro names to numeric identifiers, then produces lists of objects and access rights. The output is a Resolver tree, which the Resolver passes to a security checking mechanism.|
|4||The security module checks access rights in the Data
|5||The Optimizer determines the most effective way to access the data needed by the request.|
|6||The Optimizer scans the request to determine where locks should be placed, then passes the optimized parse tree to the Generator|
|7||The Generator transforms the optimized parse tree into
plastic steps and passes them to the gncApply software.
Plastic Steps are directives to the database management system that do not contain data values
|8||gncApply takes the plastic steps produced by the Generator
and transforms them into concrete steps.
Concrete steps are directives to the database management system that contain user- and session-specific information as well as data parcels.
|gncApply passes the concrete steps to the Dispatcher|
The Dispatcher controls the sequence in which steps are executed. It also passes the steps to the BYNET to be distributed to the AMP database management software.
|1||The Dispatcher receives concrete steps from gncApply|
|2||The Dispatcher places the first step on the BYNET - The
Dispatcher tells the BYNET whether the step is for one AMP, several AMPS,
or all AMPs - and waits for a completion response.
Whenever possible, the Teradata RDBMS performs steps in parallel to enhance performance.
|3||The Dispatcher receives a completion response from one or several AMPs and places the next step on the BYNET. It continues to do this until all the AMP steps associated with a request are done.|