If you are using block-level compression (BLC) you may have glanced over the list of 40+ DBS Control parameters that influence how this feature is behaving on your platform. Be aware that most of these parameters have been filled in with reasonable defaults for your system, and with some exceptions, you are not encouraged to experiment with them.
One parameter that might be particularly tempting to change is called CompressionLevel. This posting describes what the compression level parameter is and why you do not want to casually start increasing it.
This posting applies to Teradata Database 16.10 and greater releases.
Parsing time is often an afterthought. But sometimes there is a concern because parsing is taking longer than expected. But whether the time to accomplish parsing is becoming an issue for you or not, there are small benefits that can be enabled by creating a special workload to manage the parsing activity for all your queries. This blog posting explains why and how to set that up on your system.
Back in 14.10, some new fields related to Capacity on Demand (COD) and other types of hard limits were quietly added to ResUsage tables. You might be interested in these fields today, because they report how long queries were delayed due to hard limit enforcement. This can give you insights into whether a hard limit, like WM COD is ever being reached, and its actual impact on activity on the platform when it is reached.
Temperature-based block-level compression, also known as "Compress on Cold" was introduced in Teradata Database 14.0. Temperature-based block-level compression (TBBLC) automatically compresses infrequently accessed data and decompress frequently accessed data. The access frequency is determined by statistics collected by TVS. TBBLC may be applied on a table-by-table basis or by default on all user tables.
This blog posting provides a little background and describes the easiest way to enable TBBLC on just a few selected tables in your database.
If I told you there was a way you might be able to speed up parsing time for your queries, would you be interested?
If yes, consider "expediting" express requests. This blog posting explains what that means, how it works, and when it can help you. The goal of expediting express requests is to get the best performance you can from parsing when the system is being fully utilized.
Note: This is a rewrite of an earlier blog posting ("Expediting Express Requests") with a similar name that I posted back in 2014. Enhancements have been made to this capability since then, so it's worth giving this posting a read even if you are familiar with how the option used to work.
This is an update to an earlier posting in which data dictionary statistics to collect in Teradata Database 15.10 were recommended. This posting makes recommendations for dictionary statistics from the Teradata Database 16.10 perspective. You may not require all these statistics, but they cover the tables and columns most likely to be accessed in the data dictionary views.