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
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