René Nyffenegger's collection of things on the web | |
René Nyffenegger on Oracle - Most wanted - Feedback
- Follow @renenyffenegger
|
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
Consider the following two statements:
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.
|