A fast append is the one write operation that never rewrites anything. It
adds a manifest holding the files it wrote, carries every manifest of the
parent snapshot over into the new manifest list by reference — same path,
same sequence numbers, same first_row_id — and commits a snapshot whose
operation is append.
What that produces, in order:
- data files (
iceberg.write), one Parquet file per partition per batch;
- one manifest of ADDED entries, with null sequence numbers so that the
manifest list's own numbers are inherited, and — under v3 — null
first_row_ids for the same reason;
- a manifest list: the new manifest first, then the parent's, each keeping
the values it was committed with;
- a
Snapshot with the standard summary keys, and the metadata edits a
commit implies: last-sequence-number, last-updated-ms, snapshot-log,
metadata-log, refs.main, and under v3 next-row-id.
Row lineage (v3). The snapshot's first-row-id is the table's
next-row-id before the commit; the new manifest is assigned that same id in
the manifest list, and every data file in it inherits an id from it in order.
The table's new next-row-id is first-row-id + added-rows. Existing
manifests keep the ids they were assigned, so no two ranges overlap. That is
the rule the v3 fixture generator encodes and the reader already implements
for the other direction.
Overwrite, delete, replace and compaction are not here: they need a merge
of manifests rather than an append to them, and the iceberg-rs.mojo bridge
covers them.