There's an earlier posting that explains the earlier approach to how the parsing workload is selected:
http://developer.teradata.com/blog/carrie/2014/12/a-closer-look-at-how-to-set-up-a-parsing-only-workload
If you haven't set up a parsing-only workload, parsing will still take place based on the highest priority WD that matches on Who criteria as described in the section "How a Session Classifies to a Workload" in the text above. In the second example illustrated in that section, it could be that the WD-Medium does not have a very high priority compared to other workloads. So if you have not set up a parsing-only workload (which you may be just fine not doing), the priority at which parsing runs may be high sometimes, low sometimes, depending on your workload management setup.
The main benefit of using this approach over the previous approach is that if you do set up a workload solely for parsing priority, you don't require multiple wild card Who criteria on that workload, as you had to do with the earlier approach. Previously, you had to keep adding wild card Who classificationcritieria to a parsing-only workload if you had other workloads of a lower priority that had more Who criteria than the parsing workload had. That is because the old approach selected the highest priority workload that had the greatest number of Who criteria among the workloads that were matched. If you did not do this, then some queries did not pick the intended workload for parsing. So the old way, you had to make your parsing workload's scope artificially high. Not everyone did this, so parsing prioritization was not consistent.
The performance advantage of this new approach is likely to be small, subtle, for most sites, as parsing generally uses very little resources. But it could be more noticeable in cases where you had many queries that required multiple seconds of CPU to do the parsing, and the contention for CPU was high, and the parsing had previously been running at a low priority. You could experience faster parsing in cases such as that, and under some circumstances that could reduce the total execution time of a query, especially short-running queries. Especially since the parsing work is run on a single task and cannot be parallelized as can AMP work, and is competing against an increasing number of AMPs on the node for resources.
Thanks, -Carrie
There's an earlier posting that explains the earlier approach to how the parsing workload is selected:
http://developer.teradata.com/blog/carrie/2014/12/a-closer-look-at-how-to-set-up-a-parsing-only-workload
If you haven't set up a parsing-only workload, parsing will still take place based on the highest priority WD that matches on Who criteria as described in the section "How a Session Classifies to a Workload" in the text above. In the second example illustrated in that section, it could be that the WD-Medium does not have a very high priority compared to other workloads. So if you have not set up a parsing-only workload (which you may be just fine not doing), the priority at which parsing runs may be high sometimes, low sometimes, depending on your workload management setup.
The main benefit of using this approach over the previous approach is that if you do set up a workload solely for parsing priority, you don't require multiple wild card Who criteria on that workload, as you had to do with the earlier approach. Previously, you had to keep adding wild card Who classificationcritieria to a parsing-only workload if you had other workloads of a lower priority that had more Who criteria than the parsing workload had. That is because the old approach selected the highest priority workload that had the greatest number of Who criteria among the workloads that were matched. If you did not do this, then some queries did not pick the intended workload for parsing. So the old way, you had to make your parsing workload's scope artificially high. Not everyone did this, so parsing prioritization was not consistent.
The performance advantage of this new approach is likely to be small, subtle, for most sites, as parsing generally uses very little resources. But it could be more noticeable in cases where you had many queries that required multiple seconds of CPU to do the parsing, and the contention for CPU was high, and the parsing had previously been running at a low priority. You could experience faster parsing in cases such as that, and under some circumstances that could reduce the total execution time of a query, especially short-running queries. Especially since the parsing work is run on a single task and cannot be parallelized as can AMP work, and is competing against an increasing number of AMPs on the node for resources.
Thanks, -Carrie