 |
 |
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
| |
