The Teradata DBMS has always supported compression in a (growing) number of forms.
Version 5.0 introduced Multi-Value Compression (MVC), version 13.10 introduced Algorithmic (ALC) and Block Level (BLC) compression, and version 14.0 introduced multiple automatic compression options for Columnar tables.
These can produce disk space and associated performance savings; however, implementing Teradata compression with MVC or ALC takes man-time, which has a cost.
It also needs to be remembered that because data demographics change over time, analysis of either of these types of compression needs to be revisited regularly (which may only be once a year).
Yes, some tools will help with this, but the point of this article is to ask if the time you spend on compression is worthwhile? Is it giving you benefits that are commensurate with the costs? Like many things, this is a “cost vs. benefit” question.
I am not recommending that you remove existing MVC compression on small tables. Using MVC doesn’t impose any CPU overhead, and eliminating compression on many tables will be a lot of effort for negligible gain. If you have ALC applied to a small table, then you might get some savings.
When designing new tables or possibly when making changes to existing tables, I would recommend that the compression setting be carefully considered.
If that table is likely minor, I would consider not applying any compression. This is more process change than any remedial action that needs to be taken.