Skip to content

Support rewrite_manifests table maintenance#3631

Draft
moomindani wants to merge 6 commits into
apache:mainfrom
moomindani:moomindani/rewrite-manifests
Draft

Support rewrite_manifests table maintenance#3631
moomindani wants to merge 6 commits into
apache:mainfrom
moomindani:moomindani/rewrite-manifests

Conversation

@moomindani

Copy link
Copy Markdown

Closes #3629

Rationale for this change

Adds table.maintenance.rewrite_manifests(), the explicit maintenance counterpart of Java's Table.rewriteManifests() (Spark: rewrite_manifests). When a table accumulates many small manifests from repeated appends, scan planning slows down; this merges the current snapshot's data manifests into fewer manifests sized by commit.manifest.target-size-bytes (default 8 MB).

  • Entries are rewritten as EXISTING and keep their sequence numbers and file sequence numbers.
  • Delete manifests, and data manifests that need no merging, are kept as-is.
  • The result is committed as a replace snapshot; snapshot totals carry over unchanged (update_snapshot_summaries now handles Operation.REPLACE), and the summary reports manifests-created / manifests-kept / manifests-replaced / entries-processed, matching Java.
  • V3 tables are rejected with a clear error for now: rewriting must preserve the first-row-id of rewritten manifests, which needs the read side of row lineage (Support row lineage assignment on commit #3621). The writer-side plumbing already exists in Support writing V3 manifests and manifest lists #3624.

Related: #270 tracks automatic manifest merging on write; this PR covers only the explicit maintenance API.

Draft while the API shape settles: #3124 is introducing table.maintenance.compact() on the same MaintenanceTable, and I'd like this to land consistently with it.

Are these changes tested?

Yes, five tests using an in-memory catalog with real appends: merging three manifests into one (entry counts, EXISTING status, data unchanged, replace summary with carried-over totals), sequence-number preservation including the merged manifest's min_sequence_number, single-manifest no-op (kept as-is, not rewritten), target-size grouping, and rewrites_needed(). All fail without the implementation.

Are there any user-facing changes?

Yes: a new table.maintenance.rewrite_manifests() API.

This pull request and its description were written by Claude Fable 5.

Add table.maintenance.rewrite_manifests(), which merges the current
snapshot's data manifests into fewer manifests sized by
commit.manifest.target-size-bytes. Entries are rewritten as EXISTING
and keep their sequence numbers; delete manifests and manifests that
need no merging are kept as-is. The result is committed as a replace
snapshot whose totals carry over unchanged.

V3 tables are rejected for now: rewriting must preserve the
first-row-id of rewritten manifests, which needs the read side of row
lineage (apache#3621).

Closes apache#3629
Committing a replace snapshot that merely re-lists the same manifests
has no value; return no updates instead, and assert in the no-op test
that the current snapshot is unchanged. Document that rewrites carry
live entries only, matching the reference implementation, and add the
Spark interop integration test (data, snapshot history, file and
manifest counts, and pre-rewrite time travel verified from Spark).
tests/table/test_rewrite_manifests.py and the integration test shared
a module name, which fails mypy collection.
The target was exactly twice the first manifest's length, so a
second manifest one byte larger started its own group and the test
was flaky.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support rewrite_manifests table maintenance

1 participant