René Nyffenegger's collection of things on the web
René Nyffenegger on Oracle - Most wanted - Feedback -
 

Teradata's parsing engine (PE)

Step 1: Is request in request cache

If yes: check access rights (step 4) and go to step 7.
If no: go to step 2

Step 2: Syntaxer

Checks for the statements validity. If ok, goos to step 3, otherwise returns an error.

Step 3: Resolver

Maps identifiers in statement (such as table names and the like) to internal identifiers. This information is stored in the data dictionary.

Step 4: Security

Checks access rights needed to perform the statement.
Returns an error message if they're not granted.

Step 5: Optimizer

The optimizer's goal is to find the most effective way to execute the SQL request.

Step 6: Generator

The output of the opimizer is turned into plastic steps and passed to gncApply

Step 7: gncApply

Plastic steps are converted into concrete steps.

Step 8: Dispatcher

The dispatcher distributes the steps on the BYNET and waits for the AMPs to complete.
Consider the following two statements:
  • select foo from baz where id = 49039;
  • select foo from baz where id > 49038;
Say, id is baz' primary key. In this case, for the first statement, only one row is returned, so only one AMP is needed. However, the second statement returns many rows, so mutliple AMPs will be involved.

Step 9: Lock

If the statement needs to be serialized (in order to ensure data consistency), the necessary locks are placed.

Step 10: Operation

The actual operations are performed by the AMPs.

Step 11: End transaction

Locks are realeased.

Using explain to display access plan

Teradata has the explain sql statment that allows to show the results of the parsing engine.

Misc

The Parsing engine is a vproc and can migrate from its home node to another node within the same hardware clique if the home node fails.