Choose the right action
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
Some unsupported actions have recognized SQL procedure names. Recognition does not mean that the Iceberg provider can execute them. The SQL reference 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
- Inspect and prepare a table. Record the current snapshot, files, row count, and a business total.
- Choose data compaction, delete compaction, or manifest optimization based on what you found.
- Copy the full example into Workbench. Choose a writable Iceberg catalog before running it.
- Run the script and inspect the maintenance statement’s result. Wait for successful completion and confirmed publication.
- Refresh the table inspection and run the row checks again.
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 for the instance defaults and task limits. Use TBLPROPERTIES for saved table settings used by later writes. An individualCALL submits one maintenance operation. It does not create a recurring maintenance policy. Use the shared Observability docs for operational visibility.