If I told you there was a way you might be able to speed up parsing time for your queries, would you be interested?  

In Teradata Database 14.10.02 there is a new capability that allows you to expedite express requests, and I’d like to explain how that works, describe when it can help you, and make some suggestions about how you can use it to get the best performance you can from parsing when the system is under stress.  But first a little background.

What is an express request?

When data dictionary information is needed by modules in the parsing engine (PE), and it cannot be found in the data dictionary cache on that PE, an express request is issued.  That stream-lined request goes directly to the AMPs and attempts to find that data dictionary information.  Because the database code itself is issuing express requests (rather than an end user), and the database can trust itself to do the right thing, these very short requests are allowed to bypass the resolver, security, parsing and optimization modules and are sent directly to the AMPs.

Most express requests are single-AMP requests that go to one AMP.  If there is lock on the row hash of the dictionary row they are trying to access, an express request will be resent to that AMP with an access lock applied.   If data from the data dictionary is accessed using an access lock, that data is not cached as it is the result of a dirty read and that row or rows may be in the process of undergoing change.

Several different modules in the parsing engine can submit express requests.  The figure below lists some of the dictionary information that express requests access, and which modules issue the requests. Even a simple query may require 30 or more express requests to be issued, and they will be issued serially.  Things like the number of database objects referenced in the SQL, the number of statistics that the optimizer looks for, and the complexity of access rights can influence the amount of separate requests for data that will required.  


Assessing parsing time spent on express requests

Starting in Teradata Database 14.0 you can see the wall clock time that was spent in processing express requests. Usually this number is close to zero.  This data is in a new column in DBQLogTbl named ParserExpReq.   Below is a sample of columns from several rows of DBQLogTbl output showing ParserExpReq, intentionally selected to show variation.  The unit reported in ParserExpReq is seconds.

































In many cases ParserExpReq will be NULL.   You will see a NULL when no express requests were issued because all the data was found in the data dictionary cache on the parsing engine.  Zero means that the wall clock time for express requests was less than 0.01 seconds.  99.9% of theDBQLogTbl rows from my shared test system showed ParserExpReq values of either zero or NULL.  I would expect that to be the same on your platform.   But as you can see from the data above, taken from that same system, there were occasional times when ParserExpReq was reporting some number of seconds (close to half a minute in the worst case above), even when the CPU time for parsing was very low. 

ParserExpReq reports wall clock time for the execution of all express requests combined on behalf of a query, and will not correlate directly to ParserCPUTime.  The usual reason for ParserExpReq to be a higher number of seconds is that one or more of the express requests were blocked once they got to the AMP.   This could happen if the AMP has exhausted AMP worker tasks.

What does expediting a request do?

Expediting a request marks it for special performance advantages.  In SLES11 and current SLES10 releases, all queries within a tactical workload are automatically expedited.  As of 14.10.02 you have the capability of expediting express requests as well.  

Here’s why that might make a difference for you.  When a request is expedited it is able to use special reserve pools of AMP worker tasks (AWTs), intended for tactical queries only.  If there is a shortage of AWTs on your platform, use of these reserve pools can speed up the elapsed time of a request, as the request no longer has to wait for another request to complete and free up an AWT so that it can begin to execute.

See this blog posting on reserving AMP worker tasks for more information on how expedited requests take advantage of reserve pools:


In addition to being given access to special reserve pools of AWTs, expedited requests are given other small internal boosts that are coded into the database.  While probably not noticeable in most cases, these slight performance advantages can contribute to completing work more quickly, especially on a platform with a high degree of contention.

The standard way that express requests are assigned to AMP worker tasks

Prior to taking advantage of this enhancement in 14.10.02, express requests were sent to the AMP in a message classified as a Work01 work type message.  Message work types are used to indicate the importance of the work that is contained in the message.  Work01 is used for spawned work on behalf of a user-initiated query (such as the receiver task during row redistribution).  It is a step up from new work (which runs in Work00).  

If there is a delay in getting an AWT, Work01 messages queue up in the message queue ahead of Work00 messages (new work sent from the dispatcher), but behind all the other work types.   If there are no AWTs available in the unassigned AWT pool at the time the message arrives, and the three reserves for Work01 are in-use, the message will wait on the queue.  This can increase the time for an express request to complete.  


How express requests are assigned to AMP worker tasks with this enhancement

If you take advantage of this enhancement, then messages representing express requests that arrive on the AMPs may be able to use the Work09 work type and reserve pool.  Work09 is a more elevated work type and is the work type assigned to spawned work from an expedited request.   Use of Work09 for express requests only happens, however, if there are AMP worker tasks reserved for the Work09 reserve pool.  If there are no reserves in Work09, then Work01 will continue to be used.

For more information on work types and reserve pools read this posting:


The important point in all of this is that if you are often, or even occasionally, out of AWTs, then making sure your express requests are not going to be impacted when that condition arises could provide better query performance for parsing activities during stressful times.  

Steps you have to take

The default behavior for express requests will remain the same when you upgrade to 14.10.02 or 15.0.   In order to expedite express requests you will need to put in a request to the support center or your account team asking them to change an internal DBS Control parameter called:  EnableExpediteExp.

The EnableExpediteExp setting has three possible settings:

0 = Use current behavior, all express requests go to Work01 (the default)

1 = Parser express requests will be expedited and use Work09 for all requests if AWTs have been reserved

2 = Parser express requests will be expedited and use Work09 only if the current workload is expedited by workload management and AWTs have been reserved

If you set EnableExpediteExp = 1, then all express request for all queries will be expedited, even when the request undergoing parsing is running in a workload that itself is not expedited.   If you set EnableExpediteExp = 2, then only express requests issued on behalf of an expedited workload will be expedited. 

Marking EnableExpediteExp as 1 or 2 is going to provide a benefit primarily in situations where there is some level of AWT exhaustion and where an AMP worker task reserve pool for tactical work has been setup. You can look at ParserExpReq in DBQL to check if you are experiencing longer parsing times due to express request delays.   If you are, have a conversation with the support center about whether this is the right change for you.


rasikatyagi 1 comment Joined 06/14
16 Jul 2014

Hi All,
We are using Teradata Studio Express Version:
When we execute a single statement, it pops up message "Result set contains at or over 2,000 rows.Cancel at 2,000 rows in accordance with the settings?" Is there some setting by which it can tell us 2000 should be cancelled out of how many rows, i.e. total rows being selected in the message box itself?

carrie 595 comments Joined 04/08
16 Jul 2014

I have never used Teradata Studio Express.  I think you may have posted this question on the wrong blog.
Sorry I cannot help you.    You could try posting your question on Teradata Forum.
Thanks, -Carrie

Vinodraj 1 comment Joined 01/13
16 Jul 2014

Hi Rasika,
'Max Display row Count' is set to 2000 by default in preference.
You can increase your limit accordingly. Check out 'Max Display row Count' variable under following location
Preference -> Teradata Datatools Preference -> Result set Viewer Preference


SarathyG 1 comment Joined 09/06
15 Aug 2014

Hi Carrie,
In a senario, where we have set EnableExpediteExp = 1 and AWTs have been reserved, and we have many workloads defined under Tactical, then my understanding is that, Tactical queries are likely to be highly impacted due to high request rate for work09, as tasks from all type of workloads will compete for work09 resulting in flowcontrol ?? 
For EnableExpediteExp = 2, am able to understand the clear benefit as its extra perf booster for tactical queries(alone) in terms of parsing.
What will be the ideal senario for using EnableExpediteExp = 1 ? 

- Sarathy G

carrie 595 comments Joined 04/08
18 Aug 2014

Although it is possible,  I would not expect tactical queries to be impacted much, if at all, from competition with express requests.    Express requests for the most part are extremely fast (that is why they are named express requests) unless they have to wait for an AMP worker task.  Most of them go to one AMP, not all-AMPs.     In addition, if your tactical applications are well-tuned, primarily single-AMP requests, then they will mostly use work08 anyway, not work09, and there will be no conflict at all.
The only way to know if there is an impact like you describe is to monitor the SAWT table for inuse counts and max inuse counts for work09, before and then after you change the EnableExpediteExp setting.  If max in use counts for work09 are higher than your reserve number in either case, increase your reserve number.  
Flow control on work09 is pretty unusual.  Even if a work09 message cannot get an AWT, that work09 message will be placed in the message queue ahead of work08, work00, work01 and other lower work types, and will get off the queue sooner than those others, so flow control is very unlikely. Most commonly it is only workone messages that experience flow control.
The benefit for expedite express requests for all requests is that it adds a small boost in parsing times for all queries, which is often desirable.  However, option 2, which only provides that benefit to already-expedited requests, is a fine choice as well.  It's up to you.   
Thanks, -Carrie

danR 3 comments Joined 01/13
02 Sep 2014

Hi Carrie:
Our company is starting the migration from 13.10 to 14.10.  With the new 14.0 features, including 'columnar' partitioning, ...,  what should we look out for as possible 'hickup's - in the move.
thank you


carrie 595 comments Joined 04/08
04 Sep 2014

That's a question that is better addressed to your Teradata account team.  Or you might want to ask that question on one of the Teradata Q&A forums and get feedback from others who have been through the process.  I don't tend to get involved in the onsite migrations in any detailed way.
One thing to realize is that statitics collection functionality has been enhanced in several ways in 14.10.   You can get up to speed on that by reading two orange books by RK Korlapati on Statistics Enhancements in 14.0 and 14.10, and by checking out these postings on my blog at Dev X:
New opportunities for statistics collection in Teradata 14.0
Statistics Threshold Functionality 101
Easing Into Using the New AutoStats Feature
Thanks, -Carrie

danR 3 comments Joined 01/13
06 Jan 2015

Hi Carrie:  Reading up on Columnar,  what is the difference between column partitioning and row-based multi-value compression.   Am assuming that both use a compression and de-compression algorythm. 
thank you


carrie 595 comments Joined 04/08
07 Jan 2015

Hi Dan,
Those two are not really very comparable, other than within the columnar functionality you may experience something called autocompression if you define a partition with a type of column.  But that's very different from the multivalue compression that has been around in Teradata for a very long time.
Autocompression happens automatically for column partitions and involves potentially several different compression techniques that are applied to the data contained within a container.  One or more of these techniques may be applied to the same container, and include (for example)  NULL compression, run-length compression and trim compression.  The characteristics of the data are key to how effective autocompression will be in a column partitioned table.   See Chapter 4 in the Columnar orange book for a thorough discussion of autocompression.  There are also descriptions of autocompression and how it works in the Teradata manuals if you don't have the orange book handy.
Multivalue compression only compresses specific values within specific columns of a table and must be pre-defined by the administrator.  There is nothing automatic about it.  You have to choose the columns and the values for that column you want compressed, and it only offers one type of compression.   The actual values are moved to the table header and presence bits are used in each row to point to the actual values in the table header that have been removed from the row.  A full description of multivalue compression can be found in Teradata Database Design manual and the Data Adminstration manual if you require more detail.
The only overlap between the two is that autocompression has one type of compression that is called local value-list compression, in which often-occurring column values are placed in a dictionary local to the container.  This could be seen to be similar to MVC, where the DBA picks the columns and compresses out some number of the values for that column.    Neither approach requires decompression as the values that have been compressed out are either locally handy or in the table header in memory.
Thanks, -Carrie

SmarakDas 25 comments Joined 02/12
12 Feb 2015

Hello Carrie,
Wonderful Article. I have a few questions concerning Expediting Express Requests:
(a) You have mentioned the DBQLogTbl Column "ParserExpTime" denoting the time in seconds for Express Requests. Do the Explain Plan shows any indication of this timing.
(b) In the 2nd paragraph under "Assessing parsing time spent on express requests", you have written "You will see a NULL when no express requests were issued because all the data was found in the data dictionary". It should be 'Data Dictionary Cache of the PE' instead of simply 'Data Dictionary'. Please rectify me if I am wrong. As Express Request deals with DD & DD Cache, this line is kind of confusing for me.
(c) When you say "If there are no AWTs available in the unassigned AWT pool at the time the message arrives, and the three reserves for Work01 are in-use, the message will wait on the queue", I wish to clarify 01 thing. If the Express Request isn't expedited, then the message will wait on the queue after checking the unassigned AWT pool only. The availability of the 03 AWTs reserved for Work01 shouldn't matter as these reserved pool is meant for Work01 message originating from queries of Tactical Workload or expedited requests only. Please rectify me if I am wrong.
Thanks In Advance,


carrie 595 comments Joined 04/08
12 Feb 2015

Thank you for catching the typo where I left off "cache" after "data dictionary" above.  I have made that correction.
Express requests first look in the data dictionary cache to see if the data they need resides there.  Only if the data is not in the dictionary cache will the express have to go the AMPs.
The explain does not carry any information about express request execution time.  The purpose of explain text is to show the query plan and the estimates that were used to produce that plan, not report on performance data.  That is why express request performance information is in DBQLogTbl.
As for question #3, if express requests are not expedited they will use the Work01 work type.  If there are no available AWTs in the unassigned pool they will look to see if there are any reserves is the reserve pool of 3 for the 01 work type.  The work01 reserve pool is used for express requests and also for unexpedited work that has been spawned from a work00 work type.   Queries that are tactical or that have been expedited will use the work08 work type and work08 will only have  a reserve pool if the DBA has defined one.   Expedited requests will not use the work01 reserve pool.
Thanks, -Carrie

Rahul 3 comments Joined 05/09
19 May 2015

Thank you for the extremely informative blog.
What in your opinion should be considered a threshold value for ParserExpReq which will warrant the need for expediting express requests ?
Or, should we try to determine if Work01 AWT exhaustion may be causing a high value for ParserExpReq and then make a decision as to whether express requests need to be expedited ?
- Rahul.

carrie 595 comments Joined 04/08
20 May 2015

I don't have a threshold value in mind when it comes to ParserExpReq.  You could compare it to ParserCPUTime.   Some requests are more complex and may have high ParserCPUTime as a results.   Those requests may also have higher ParserExpReq because of that.   Each request is different. 
The two conditions that I would suggest you pay attention to before considering expediting express requests are the following:
                - Is anyone complaining about long parse times, or have ParserExpReq times gotten decidedly  longer?
                -Are you exhausting AMP worker tasks at the time when long parsing times are being detected?
If you not exhausting AWTs, then there is little value in expediting express requests.
Thanks, -Carrie

Sandeepyadav 27 comments Joined 09/13
04 Jun 2015

Hi Carrie,
I have a query regarding the AWTs category WorkType08/09/10:
Are AWTs assiggn to WorkType08,WorkType09,WorkType10 when we reserve AWTs in viewpoint in Ruleset (General->Limits/reserve-> Reserve Awts for tacticals)?. Is there any other way to Assigen AWTs to WorkType08/09/10.?

Thanks, -Sandeep.

carrie 595 comments Joined 04/08
10 Jun 2015

Starting in 13.10, Viewpoint Workload Designer is the only way you can interact with workload management settings, including setting reserves for tactical work.
Thanks, -Carrie

GDHAR 7 comments Joined 08/14
14 Jul 2015

Hi Carrie,
Good day!
Data is not reflecting in viewpoint lock viewer portlet even after populating in base table dbc.dbqlxmllocktbl. Showin below error
***Unable to get lock information! [Teradata Database] [TeraJDBC] [Error 9134] [SQLState HY000] AS_SHRED_BATCH:Error in function AS_SHREDTB: Insufficient memory to complete the XML operation.***
I have tried by increasing the XML_MemoryLimit value to 16 MB from 4 MB default value, but still getting same issue.
Can you please share your thoughts on the same.

carrie 595 comments Joined 04/08
16 Jul 2015

I think you may have posted this question under the wrong blog.  The topic here is expediting express requests in the database. 
If you have Viewpoint questions, you might want to address those to someone with more background on Viewpoint and that particular portlet.  I do not have experience in that area, so I am not able to help you.
Thanks, -Carrie

oshun 3 comments Joined 07/10
03 Aug 2015

Hi Carrie, just to be sure that I get it right: This new feature of "express requests" basically means that there is a work type with higher priority used for tactical workload(08/09). Is this correct?

Without this feature, it was classified as "spawned work / 01" and was put into the queue with higher priority than "New work 00", but with the new feature it's moving up even much higher in the work type priority hierarchy. Is this correct?
Thanks in advance

visit my private blog at http://www.dwhpro.com

carrie 595 comments Joined 04/08
06 Aug 2015

"Express requests" are not a new feature.  Did you mean "the ability to expedite express requests"?  That is a new capability.
If that is what you meant, then what are saying is correct.   Express requests will run using a higher AMP worker tasks message worktype, the same work type as tactical work.  However, another big advantage is that express requests can then use reserved AMP worker tasks.  So if an AMP has exhausted all its AWTs, the express requests can still get through very quickly using the reserved tactical AWTs. 
This use of higher work types by express requests only happens if there are AWTs reserved for tactical requests, and if the reserves are 2 AWTs or greater.
However, if you never run out of AWTs, then there is no benefit in expediting express requests.
Thanks, -Carrie

StevenSchmid 13 comments Joined 07/11
29 Nov 2015

Hi Carrie
I'm currently working on a 13.10 system, which is due to be upgraded to 15.0 at the end of the year.  We are using Viewpoint 15.0
The system is currently CPU bound and frequently goes into flow control, but one interesting thing I have seen in Workload Designer, is that all the workloads have reserved AWTs = 0, and Max Expedited AWTs = 62.
What would the recommended setting be for "Max Expedited AWTs", and should it only be set for tactical/short type queries ?

Steven Schmid
Teradata DBA
Canberra, Australia

carrie 595 comments Joined 04/08
01 Dec 2015

I am assuming you are on SLES 10, as you are on 13.10 database software.
The two settings you mention ("Reserved AWT" and "Max Expedited AWTs") are not set at the workload level.  They are set in one place as a sort of global setting, on the Viewpoint Priority Distribution screen.    Once they are set, they will be applied to all workloads with the tactical enforcement priority.  Non-tactical workloads will not be impacted by those two settings.
So if you don't have any tactical workloads, it doesn't really matter how you set them.
The default for Max Expedited AWTs is 50, the same as the limit of AWTs allowed to support WorkNew work type messages.  All the Max Expedited AWTs does is put a limit on the number of AWTs that can be used at any point in time to support new expedited work, which runs in Work08 work type.  Requests coming from expedited workloads (workloads with the tactical enforcement priority), will always use worktypes 8, 9 and 10, rather than work types 0, 1, and 2.  Even if there are no reserved AWTs specified.  This means tasks coming from expedited workloads will be in the work message queue ahead of new work that is not expedited, if there is AWT exhaustion.
This is explained in the most recent AMP Worker Task orange book, Section 4.5, if you can find that in the orange book repository.  The title is: 
                AMP Worker Tasks and ResUsage Monitoring for Teradata 14.0.
I know you are only 13.10 just now, but most of the content of this orange book will apply to you, except some of the ResUsage table fields you won't see until you get to 15.0.
If you do have tactical workloads, you might want to think about using reserved AWTs so that tactical work can always run even if non-tactical work is delayed by flow control episodes. Those tradeoffs are explained in the AWT orange book as well.
In general, the Max Expedited AWTs is fine at the default of 50, but if you expect the concurrency level of new expedited work to exceed 50, and you want to minimize blocking waiting for an AWT for those types of messages, you could increase Max Expedited AWTs to the expected concurrency levels.  A better approach would be to analyze ResUsageSawt data and look at the max inuse counts for work08 at your busiest times, and if the counts are less than 50, leave 50 as the default.  If the counts are above 50 then you could increase the setting to be a point or two above the max work08 count number.
And if you want to expedite express requests once you get on 15.0, as described in this blog posting, you will need to specify at least 2 in the Reserved AWT setting, even if you do not have tactical work.
Thanks, -Carrie

StevenSchmid 13 comments Joined 07/11
02 Dec 2015

Hi Carrie
Thanks for your detailed reply.
Yes, we are on SLES10 TD13.10, will upgrade to SLES11 sometime in the new year, after the 15.0 upgrade.
I have found the Orange book you mentioned, very informative.
I have a question, if tactical workloads are not defined, does that mean that the AWTs assigned to Work08,09,10 will go unused, or with 13.10 do tactical queries go to Work01 ?  Or, if Work08,09,10 are active, are they only assigned AWTs if the "Reserved AWTs" are assigned a number > 0 ?  If Work08,09,10 are assigned AWTs with the "Reserved AWTs=0", will setting up a tactical workload (single/few amp or CPU < 2 secs) make use of the AWTs at no extra AWT overhead, as we currently get flow control.  I will do some analysis, and if the number of queries classifying into the tactical workload is large, then I can assign some reserved AWTs which will be taken from the 62 AWT reserve pool (default 80 AWT).
Another question if you don't mind, is I was also considering increasing the AWTs from 80 to say 90, however we only have 96GB 6650H nodes.  I did see on one of your blogs, that this would increase memory on the nodes, I think from memory it would be "30 amps/node x 10 newAWTs x 2 MB = 600 MB/node", which doesn't seem excessive.  I can also discuss this with Teradata Customer Services, as the Customer really does not want to invest in additional hardware if at all possible

Steven Schmid
Teradata DBA
Canberra, Australia

carrie 595 comments Joined 04/08
04 Dec 2015

SLES 10 and SLES 11 work in a similar way when it comes to the AWT work types different work messages will be assigned.   In SLES 10, if a workload has a tactical enforcement priority it is considered an "expedited" workload. All of its requests are expedited.  In SLES 11 any workload you place on the tactical tier is considered "expedited".    All work messages that arrive on the AMPs from requests that come from an expedited workload will have a work type of either Work8, Work9, or Work10.   It doesn't matter if there are reserve pools set up for those work types, tactical messages will still use work8/9/10.
Whether or not you choose to reserve AWTs for work8/9/10 is independent of the use of those work types by messages that come from expedited workloads.  If you do set a reserve for tactical requests, that will hold back some number of AWTs to be used only for expedited requests.   There is no extra overhead in using reserved AWTs that come from a reserve pool for work8 work type, for example.  It is the same internal effort to grab an AWT from the work8 reserve pool as from the work00 reserve pool, or from the unassigned pool.  In fact, the reserve pools are really logical constructs, in reality it's all one big pool of AWTs, with counters keeping track of reserves and who gets them and how many AWTs to leave in the pool to cover unused reserves.
If you do not have tactical work but you have defined reserves for work8/9/10, you will be holding back some number of AWTs that non-expedited work cannot use, so that could have a negative impact.  That is the only downside I can think of for NOT reserving AWTs for expedited work if you find yourself running out of AWTs or ever in flow control.  And even if you don't have tactical requests, as this posting above describes, if you have defined at least 2 reserves, parsing express requests can run there as well, so that could help you out.
I would suggest you talk to CS or the GSC before adding AWTs, just to make sure someone looks at your hardware and other details and make sure you won't run out of memory.   It's a conservative step to take, and the right thing to do. 
Thanks, -Carrie

kqn1 4 comments Joined 05/16
13 May 2016

Hi Carrie,
Can you expand on the ParserExpReq values in the DBQLogTbl?
When should I be concerned as I see many occurences of ParserExpReq with values of 5 or higher (sometimes 30+) and happenning quite frequently.
For example, during a peak load hour during a day long process, I totaled up over 10,000 secs of ParserExpReq in that single hour.
Is this a clear sign for expediting express requests?
Also, in what situations are expediting express requests NOT a good idea.
Note: we are on TD 15.10.
Thanks in advance!

carrie 595 comments Joined 04/08
20 May 2016

What is a "high" value for ParserExpReq depends on the the complexity of the queries being executed and whether the system is congested or not.   You could try to establish a "normal" ParserExpReq time for your queries and then look for deviations from that value as the system gets busy.   If you are not getting any user complaints about long parsing times, you don't necessarily have to do anything when parserexpreq is high.  The express requests will get executed eventually, they will just take longer.   However, express requests do use a higher work type than worknew requests, so if they get queued waiting for an AWT they should be one of the first requests off the queue.
However, expediting express request is a way to shorten the time spent on express requests when there is a shortage of AWTs, if that is an important thing to manage at your site.   Express requests used during parsing/optimizing are very short, and only hold an AWT for an extremely short amount of time, so there is really no down-side to expediting them.  Parsing happens only once per query, so it's usually infrequent.
Something to be aware of, there are a few cases where express requests issued by the DBS are all-AMP requests.  One case is when all-AMP random AMP samples are being collected.   The other case can happen during collect statistics execution.  The update, delete and insert counts (assuming USECOUNT logging is turned on) are kept in a special cache in each PE.  When collect stats is issued it flushes the UDI count cache and writes the contents to disk.  The counts from all PE's caches are aggregated and express requets are used to send them down to the right AMPs to update the new DBC.ObjectUsage table.  So you may see somewhat higher than usual parserexpreq times for collect statistics statements when you collect statistics.   If you expedite express requests, that will include this occasional all-AMP express requests that are unrelated to parsing.
If you are running out of AWTs and that is slowing down parsing times for your requests, expediting express requests is a reasonable step to take.  But as with everything when you make a change, you should monitor the reserved AWT in-use counts and make sure the max08 and max09 numbers to not exceed their reserves.
Thanks, -Carrie

kqn1 4 comments Joined 05/16
08 Jun 2016

Thanks for your previous response.  I do appreciate the additional details provided.  I have a couple follow-up questions regarding the EnableExpediteExp setting.
1) Let's say we set this EnableExpediteExp to the value of 1, will this take effect immediately or do we need to restart anything?  I have attempted to find more information about this but am unable to find much information on this.
2) Once this setting is effective and we throw a workload at it, what metrics in which tables/fields can I look at to confirm whether this setting is effective and is helping with performance of the targeted workload.
Best regards.

carrie 595 comments Joined 04/08
10 Jun 2016

A change to the EnableExpReq does not require a restart.
You don't "throw a workload  at it" because the EnableExpReq setting is applied universally, it is not targeted to individual workloads.  Once set to 1, then all parsing for all queries will have their express requests expedited (assuming you have made the tactical reserve pool to be at least 2).
The only way to guage the effectiveness of such a change is to compare the values in the DBQLogTbl field ParserExpReq before the change and after, and see if it the values for the same or similar queries have gone down during times when AWTs are exhausted.  As I said before, changing this setting will not have any impact on how long express requests run unless the system is out of AWTs and express requests have been waiting to get an AWT.   So if you do a before and after comparison of the ParserExpReq field, it has to be based on the "before" time being at a time when the system was out of AWTs and the "after" time being at a time when the system was similarly out of AWTs.  
A precise comparison will not be possible because it is unlikely that the before and after situations will be the same (same number of AMPs out of AWTs, same number of AMPs experiencing flow control, etc.).  In addition, express requests are not issued at all if the data dictionary information is in the dictionary cache, so at different times the same query may report different values in ParserExpReq solely because of dictionary caching, or non-caching.   The best you can hope for is that you will see some overall reduction in the time it takes for a group of queries to execute express requests during times of congestion.
Just a reminder that because EnableExpReq is an internal DBS Control setting, it is best to contact the support center or CS and ask for their advice and assistance in making changes to this setting.   It is intended that changes to Internal DBS Control settings be managed by Teradata personnel.
Thanks, -Carrie

kqn1 4 comments Joined 05/16
13 Jun 2016

Many thanks for your guidance!

You must sign in to leave a comment.