Row Header Compression - Advanced SQL Engine - Teradata Database

Database Design

Product
Advanced SQL Engine
Teradata Database
Release Number
17.05
17.00
Published
June 2020
Language
English (United States)
Last Update
2021-01-22
dita:mapPath
qby1588121512748.ditamap
dita:ditavalPath
lze1555437562152.ditaval
dita:id
B035-1094
lifecycle
previous
Product Category
Teradata Vantageā„¢

The term row header compression applies only to column-partitioned tables and column-partitioned join indexes, and only when their data is stored in COLUMN format. Row header compression is a lossless method.

Teradata Database packs column partition values into a containers up to a system-determined limit. When that limit is reached, it begins packing column partition values into a new container.

The column partition values packed into a container must be in the same combined partition to be packed into a container. The row header occurs once for a container, using the rowID of the first column partition value as the rowID of the entire container, instead of storing a row header for each column partition value. Teradata Database can determine the rowid of a column partition value by its position within the container.

If many column partition values can be packed into a container, row header compression can greatly reduce the space needed for a column-partitioned object compared to the storage required for the same object without column partitioning.

If only a few column partition values can be packed in a container because of their width, it is possible for there to be a small increase in the space needed for a column-partitioned table or NoPI join index compared to the space required by the object without column partitioning. In this case, ROW format may be more appropriate than COLUMN format for storing the object.

If only a few column partition values can be stored using ROW format because the row partitioning is such that only a few column partition values occur for each combined partition, it is possible for there to be a very large increase in the space required to store a column-partitioned object compared to the space required for the same object without column partitioning. In the worst case, the space required to store a column-partitioned object can increase by up to nearly 24 times.

If this occurs, consider one of the following alternatives.

  • Alter the row partitioning to produce more column partition values per combined partition.
  • Remove column partitioning from the object definition.