 |
 |
Archives of the TeradataForum
Message Posted: Wed, 11 Sep 2002 @ 19:10:27 GMT
| Subj: | | Re: Transactions, requests, statements, macros |
| |
| From: | | Dieter Nöth |
| | Verdammt! Dieter is right. Don't you hate it when that happens? :-) | |
No, not me ;-)
btw. perfect german
| | As output #1 below shows, Dieter is right: the macro does a fast-path insert/select. I think, however, that this must be
a special optimization for this one case. In general, it would not be possible to execute every statement in a macro "in parallel".
In output #2, I show an example: a select followed by an insert. Here the select must happen either before or after the insert.
Fortunately, it happens just where you would expect it. | |
In general, it would not be possible to execute every statement in a multistatement "in parallel". Only independent statements my
be parallelized.
But you still don't believe me that a macro is treated the same as a multistatment ;-) Did you ever create a multistatement or a
macro too complex for the optimizer exceeding the number of [active] spool files? Neither rewriting the multistatement as a macro
nor splitting the macro in several nested macros is a workaround. When the PE parses a multistatement it's resolved to an initial
parse tree and then passed to the optimizer. When the PE parses a macro it's resolved to an initial parse tree and then passed to
the optimizer.
It's just like using a view vs. submitting the view's source code. When the PE parses a view it's resolved to an initial parse
tree and then passed to the optimizer. The optimizer doesn't know about the parse tree's origin. (As you probably know, sometimes
there may be a different plan, but this is usually considered a bug)
Dieter
| |
