 |
 |
Archives of the TeradataForum
Message Posted: Mon, 14 Nov 2005 @ 20:05:32 GMT
Subj: | | Re: Stored procedures results |
|
From: | | Eric Friedman |
| This penalty is much like the penalty paid for doing an ORDER BY in Teradata, which has to be done in one AMP. | |
| Absolutely not true. All AMPs locally order rows; the final merge is done by BYNET/PE in the course of returning the answer
set to the client. | |
I stand corrected about where the final ORDER BY processing is being done. Nevertheless, the point remains that the final ORDER BY is
necessarily a serial, not parallel, process being done by one component before the results are returned. This is identical in concept to the
serial process of assembling the local results of a SP executed in parallel locally by each processor.
There is no reason (at least in Oracle) why most of the heavy lifting in a SP cannot be done in parallel if the SP is properly written to take
advantage of parallelism. The same should be even more true for Teradata's massively parallel architecture.
Eric Friedman
| |