I've been receiving a warning message in my BTEQ logs indicating that a particular request is being executed in "Intpreteve EVL Code."
I looked it up and here's what the docs say about this:
3705 Request executed in interpretive EVL mode.
Explanation: This is a warning only, not an error. It indicates that the current request will be executed using interpretive EVL code rather than executable EVL code. Cases where this warning will be returned are: a) Ran out of p****r tree segments when trying to generate the executable EVL code. b) Ran out of Plastic Step segment when trying to fit both interpretive EVL code and executable EVL code in the Plastic Steps. c) Ran out of space in the concrete step segment when building one large single step. In an attempt to save space, the compiled is replaced with the interpretive EVL code. The only remedy is to simplify the query.
Generated By: GNCStEvl, GncApply.
For Whom: DBA User and System Support Representative.
Note: The request is still processed despite the warning. Remedy: This message is for information only. To avoid the warning, user may increase the DBS Control Record field MaxP****TreeSegs for case (a) and field StepsSegmentSize for case (b). See Teradata Utilities Manual for information on DBS Control fields.
My Questions: What is EVL in the first place? Is the performance reduced by running in interetive mode?
EVL is the Teradata expression evaluator component. Its purpose is to evaluate SQL conditional expressions (e.g. a WHERE clause) or value-producing expressions (e.g. a SET expression in an update statement). In its original implementation, the EVL executor was a byte-code interpreter. A component of the p****r is responsible for compiling the SQL expression into byte code ("EVL code"), which is then executed (typically) in the AMPs. In V2R1, the p****r was given the ability compile the EVL code into native machine code. This improves performance greatly when the EVL code is executed many times (for instance when scanning a large table) or where the compiled request is executed repeatedly from the request cache. The execution engine has the ability to execute either the EVL code ("interpretive mode") or machine code.
EVL code is much more compact than the equivalent machine code, so there may be extreme cases of very complex SQL expressions where the generated machine code consumes too much memory or some other limited resource, in which case the SQL p****r reverts to interpretive mode.
BTW, does anybody know why the forum software replaces the word "P A R S E R" in my text with "p****r"?
Thanks for the replies. In reveinge the logs, the performance is not much difference. Maybe 3 minutes instead of 2. Even doubled it wouldn't cause a concern. The statement is rather long with lots of CASE statments and substringing along the way.
I feel better though understanding what is going on.