Deleting Rows from a Column-Partitioned Table - 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
Consider the following information before deleting data from a column-partitioned table.
  • A DELETE ALL request or an unconstrained DELETE request takes the fastpath DELETE for any table. If specified within an explicit transaction in Teradata session mode, the DELETE request must be the last statement of the last request of the transaction.

    Similarly, if the column-partitioned table is also row-partitioned, Vantage can do a fastpath DELETE. For these cases, Vantage recovers the space that had been used by the deleted rows.

A fastpath optimization is one that can be performed faster if certain conditions are met. For example, in some circumstances DELETE and INSERT operations can be performed faster if they can avoid reading the data blocks and avoid transient journaling.

  • For all other cases, a DELETE request uses a scan or an index on a column-partitioned table. The rows are marked as deleted in the delete column partition without recovering the space, but both LOB space and index space is recovered. If column partitions with ROW format do have their space deleted and if all column partitions have ROW format, the row is not marked as deleted in the delete column partition.

    Therefore, only delete rows in this manner for a relatively small number of rows and use the form of DELETE request described in the previous bullet to delete large amounts of rows.

    The space is recovered from the column-partitioned table when all the rows are deleted at the end of a transaction or when the entire row partition that contains the deleted rows is deleted at the end of a transaction.