If each PE supports upto 120 sessions and each session can run 16 requests in parallel and each AMP can run 80 tasks in parallel,
does this mean that we need minimum 24 AMPs ((120*16)/80)???
this is a bit confusing question and the short answer is: no.
There's no direct correlation between sessions, requests and AMP worker tasks.
Thanks for the response Dieter.
Just wanted to understand, how much the default system can handle the requests simulatenously....
We say that the limitations of :
a. one PE can handle 120 sessions in parallel (http://www.info.teradata.com/HTMLPubs/DB_TTU_14_00/Utilities/B035_1102_111A/Gtwglobal.36.001.html)
b. Each session can run 16 requests in parallel
c. Each AMP will 80 tasks in parallel
1. PE sessions, handled in parallel would be = 120 sessions * 16 requests = 1920
2. Tasks handled by each amp = 80 in parallel, So No.of Amps required to handle 1920 requests would be,
1920 / 80 tasks = 24 AMPs (Does this mean that we require minimum 24 AMPs to handle 1920 requests for the above mentioned limitation)
Is this correct ?
so, considering the above 3 limitations, does this mean that if we have one PE, then will the node
As noted by Dieter, there is not a relationship between the amp worker task (AWT) and the session. When a session is logged on but not executing, it uses no AWTs. When a request is submitted, that request is decomposed into a series of steps that must be executed in the database to satisfy the request (visible via EXPLAIN). Then each of those steps is submitted to the AMPs in sequence until the result is created and returned to the source of the request. Each step may require one or many AWTs on one or many AMPs to execute based on the type of step and the distribution of the data being accessed - frequently one step requires one AWT per AMP since the data for tables in Teradata is distributed across all AMPs.
An AMP contains some number of AWTs (default 80). Each of these AWTs is a stateless process that executes steps from a queue of steps that it is responsible for. It takes a step off the queue, processes it and returns a status to the sender of that step, then takes the next step off the queue. The AWT therefore does not stay associated with the session, transaction or request for any longer than the processing of a single step. This makes it possible for a small number of AWTs per AMP to process a very large number of concurrent requests from a very large number of connected sessions. If an AWT is not available at the moment a step is sent, it simply gets queued until an AWT becomes available.
P.S. A single session can have up to 16 result sets active at a time but it can only be executing one SQL request at a time.