Row Structure for Containers (COLUMN Format) - Teradata VantageCloud Lake

Lake - Database Reference

Deployment
VantageCloud
Edition
Lake
Product
Teradata VantageCloud Lake
Release Number
Published
February 2025
ft:locale
en-US
ft:lastEdition
2025-11-21
dita:mapPath
ohi1683672393549.ditamap
dita:ditavalPath
pny1626732985837.ditaval
dita:id
ohi1683672393549

Vantage packs column partition values into a container up to a system-determined limit and then packs the next set of column partition values into a new container. The column partition values within a container must be in the same combined partition to be packed into that container.

A column partition represents one or more table columns of a table. A column partition that has COLUMN format is represented as a series of containers that hold the column partition values of the column partition.

A container consists of a header and column partition values followed by autocompression bits at the end, with free space in between.The free space is allocated so that column partition values and autocompression bits can grow toward each other using the free space without moving around the values and changing the row size.

A newly constructed container in memory starts at the maximum allowed size and, therefore, a large free space. After the container fills up or there are no more column partition values to add for the current DML request, the container can be reduced in size (as described later) and written to disk. If there are still more column partition values to add for this request, Vantage starts a new container in memory.

When new column partition values arrive to be appended for a subsequent DML request and there is a last container for the combined partition in which the column partition values are to be appended, and subsequently insufficient free space is available for appending the next new column partition value in this last container, and the container was reduced in size when last written (as described later), Vantage expands the container in memory to its maximum allowable size if that accommodates an added a column partition value. If the container becomes full, the container can be reduced in size (as described later), and written to disk. The process begins again with a new container.

Before writing a container that has reached its maximum size, when there are no more column partition values to be added to by a DML request, there is sufficient free space to add more column partition values, but its free space exceeds a system-determined percentage of its size without the free space, the database reduces its free space to be within this percentage.

Free space can occur in the last container for each combined partition. If there are a large number of combined partitions, the sum of the free space can add up to a significant amount of unused disk space. Therefore, keep this total unused space to a small percentage of the table or join index size. However, having significant free space in the last container minimizes the copying of a container to a larger memory area to accommodate new column partition values.

When writing a container that cannot hold additional column partition values, necessitating the start of a new container, the free space for the container is reduced to 0 or near zero. The last container need not be written if only read and if there is insufficient free space to add another column partition value, but the remaining free space is small. However, if a container has too much remaining free space, the database must remove the free space, and the last container row must be written.

This does not apply to a container for the delete column partition and is autocompressed.