The goal of default workloads is to offer simplicity, ease of use, and uniformity across processing components.
With default workloads, all active queries running on VantageCloud Lake that are not otherwise assigned a priority are automatically given a priority based on their query characteristics. Whatever the Teradata optimizer determines is the estimated processing time for a query determines what priority it will be assigned. The optimizer produces these query estimates when it builds a query plan.
New automatically assigned workloads have been introduced into VantageCloud Lake workload management. With these new default workloads (illustrated the the second table below), all active queries running on VantageCloud Lake that are not otherwise assigned a priority are automatically given a priority based on their query characteristics. Whatever the Teradata optimizer determines is the estimated processing time for a query determines which of these new default priorites will be assigned. The optimizer produces these query estimates when it builds a query plan.
For example, all queries expected to be very short (that have an estimated processing time 1 second or less) start executing at a very high priority. However, if any of these queries consumes more than a very small amount of CPU or I/O they will be demoted to a lower priority. On the other hand queries with more substantial estimated processing times will be assigned a starting priority that is somewhat lower in priority. If they run longer than expected, they will also be demoted to a lower priority. A total of four different default priorities are in place to support automated prioritization and demotion.
This automatic priority assignment can be overridden by assigning particular users one of the other default priorities based on account string. Queries submitted by users who have been assigned a priority in their account string will all execute at that specified priority and will never be demoted.
You can override the automatically-assigned priorities by assigning specific users to one of the five non-automatic priorities that are based on account strings, as shown in this table:
| Workload Name | Workload Priority or Access Level | Timeshare Access Rate | Workload Classification |
|---|---|---|---|
| T-WD | Timeshare Top | 8 | ACCOUNT='$R' 1 |
| H-WD | Timeshare High | 4 | ACCOUNT = '$H' |
| M-WD | Timeshare Medium | 2 | ACCOUNT='$M' |
| L-WD | Timeshare Low | 1 | ACCOUNT = '$L' |
| Tactical-WD | Tactical | Not applicable | ACCOUNT = '$TA' |
| 1 With the introduction of Teradata Active System Management (TASM) over a decade ago, the highest default priority in Teradata was changed from "Rush" to "Timeshare Top" and is represented today by the T-WD workload name. However, to be backward compatible, the user account string value that maps to the T-WD workload was left as '$R', which represents the earlier Rush workload. Any user associated with an account string starting with '$R' will be mapped to the Timeshare Top workload named T-WD. | |||
These workloads use estimated processing time as classification and contain exceptions that demote queries to a lower priority based on a threshold of CPU usage.
| Workload Name | Workload Priority or Access Level | Timeshare Access Rate | Workload Classification | Exception | Exception Action |
|---|---|---|---|---|---|
| TC | Tactical | Not applicable | Total (estimated) processing time <=1 And not ALL-AMPS |
Standard tactical exception | Change to TT |
| TT | Timeshare Top | 8 | Total (estimated) processing time <= 1 second | Total CPU > 5 seconds | Change to HH |
| HH | Timeshare High | 4 | Total (estimated) processing time > 1 second <= 10 seconds | Total CPU > 45 seconds | Change to MM |
| MM | Timeshare Medium | 2 | Total (estimated) processing time > 10 seconds <= 120 seconds | Total CPU > 240 seconds | Change to LL |
| LL | Timeshare Low | 1 | Total (estimated) processing time > 120 seconds | Not applicable | Not applicable |
Access rate expresses the relative increase in resources (CPU and I/O) made available to queries running at that access level (Timeshare High, for example), compared to the level of resources available to queries running in the Timeshare Low access level. For example, a query running in Timeshare Top (T-WD) will receive 8 times the resources as a query running in Timeshare Low, 4 times the resource as a query running in Timeshare Medium, and 2 times the resource running in Timeshare High.
This example shows how to assign a user to the workload H-WD, which runs at the Timeshare High priority:
MODIFY USER medium_user1 AS account='$H';
The account string name must be placed in the User or the Profile record in the Data Dictionary. From that point on, all the queries issued by the user will be run at that priority on both the primary cluster and on the compute cluster. If a query is submitted by a user who does not have an account string specified in their User or Profile record, that query will run in one of the automated priority workloads based on estimated processing time.
Passing Priorities Between Primary Clusters and Compute Clusters
A query is associated with one of the four Timeshare workloads if the user who submitted the query carries one of the expected account strings in their User or Profile record. If the user has been assigned this account '$H', for example, all of their queries will execute under the control of H-WD workload and run at a high priority.The workload name and the account string are passed across the Query Fabric to the compute cluster at the time the primary cluster is transferring control to the compute cluster. This makes sure that any priority that has been established on the primary cluster will be honored on the compute cluster as well.