> ## Documentation Index
> Fetch the complete documentation index at: https://docs.e6data.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Table maintenance

> Table maintenance improves the physical layout of an existing table. Use it to combine small data files, combine positional-delete files, or reorganize manifest metadata. Start by 

ReferenceApplies to: Unified engine deployments

Table maintenance improves the physical layout of an existing table. Use it to combine small data files, combine positional-delete files, or reorganize manifest metadata. Start by inspecting the table, choose one action, then verify both the operation result and the visible rows.

## Choose the right action

| What you find | Action | What should improve |
| - | - | - |
| Many small data files | [Compact data files](https://docs.e6data.com/transformation/sql/maintenance/compact-data.md) with bin packing | Fewer files for the same visible rows |
| Data layout does not match common filters | [Sort or Z-order compaction](https://docs.e6data.com/transformation/sql/maintenance/compact-data.md#sort-by-a-column) | A layout better suited to those filters |
| Many positional-delete files after row changes | [Compact delete files](https://docs.e6data.com/transformation/sql/maintenance/compact-deletes.md) | Fewer delete files with the same visible rows |
| Many small manifests | [Optimize manifests](https://docs.e6data.com/transformation/sql/maintenance/manifests.md) | Better-organized file metadata |
| Future writes keep creating unsuitable files | Set [TBLPROPERTIES](https://docs.e6data.com/transformation/sql/tblproperties.md) | Better defaults for later writes |

A manifest is an Iceberg metadata file describing data files or delete files. Rewriting manifests does not compact the table's data files. Changing a table property does not rewrite files already stored.

## Current Iceberg support

| Action | Supported by the current provider? |
| - | - |
| Data compaction: bin pack, sort, and Z-order | Yes, for Iceberg format v2 |
| Positional-delete compaction | Yes, for Iceberg format v2 |
| Manifest optimization | Yes, for Iceberg format v2 |
| Snapshot or history expiry | No |
| Orphan-file or obsolete-metadata cleanup | No |
| Table or partition statistics computation | No |

Some unsupported actions have recognized SQL procedure names. Recognition does not mean that the Iceberg provider can execute them. The [SQL reference](https://docs.e6data.com/transformation/sql/maintenance/reference.md) separates accepted names from executable actions.

> **Use a format-v2 practice table.** New Iceberg tables default to v3. The recipes explicitly create v2 tables because the current native maintenance provider requires that version. An existing v3 table cannot be downgraded to v2 to run these examples.

## Follow one complete workflow

1. [Inspect and prepare a table](https://docs.e6data.com/transformation/sql/maintenance/inspect.md). Record the current snapshot, files, row count, and a business total.
2. Choose data compaction, delete compaction, or manifest optimization based on what you found.
3. Copy the full example into Workbench. Choose a writable Iceberg catalog before running it.
4. Run the script and inspect the maintenance statement's result. Wait for successful completion and confirmed publication.
5. Refresh the table inspection and run the row checks again.

The recipes use inline `VALUES` data. They do not require Hub, SF1, or any external sample dataset. They do need a writable Iceberg catalog, storage access, and maintenance execution capacity.

## Results that mean something

Compare the result counters with the table inspection. A reduction in file count is useful evidence for compaction. Matching row counts and totals help check that the logical data was preserved. They are different checks.

A successful no-op is valid when no files qualify. Do not assume maintenance failed because it rewrote zero files. Do not assume a smaller file count proves faster queries; compare the actual queries you care about.

Snapshot changes can also come from concurrent writers. Use a quiet practice table when learning or comparing exact before-and-after results.

## Defaults and ongoing work

Use procedure arguments to control one call. Use [maintenance configuration](https://docs.e6data.com/transformation/operations/configuration/maintenance.md) for the instance defaults and task limits. Use [TBLPROPERTIES](https://docs.e6data.com/transformation/sql/tblproperties.md) for saved table settings used by later writes.

An individual `CALL` submits one maintenance operation. It does not create a recurring maintenance policy. Use the shared [Observability](https://docs.e6data.com/transformation/operations/observability.md) docs for operational visibility.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.