Skip to content
65 changes: 65 additions & 0 deletions api/src/main/java/org/apache/iceberg/DeletionVector.java
Original file line number Diff line number Diff line change
@@ -0,0 +1,65 @@
/*
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for additional information
* regarding copyright ownership. The ASF licenses this file
* to you under the Apache License, Version 2.0 (the
* "License"); you may not use this file except in compliance
* with the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing,
* software distributed under the License is distributed on an
* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
* under the License.
*/
package org.apache.iceberg;

import java.nio.ByteBuffer;
import org.apache.iceberg.types.Types;

/**
* Deletion vector information for a tracked file entry in a V4 manifest.
*
* <p>This encapsulates both inline and out-of-line deletion vector content. This struct must be
* defined for types 1 (POSITION_DELETES) and 5 (MANIFEST_DV).
*/
public interface DeletionVector {
Types.NestedField OFFSET =
Types.NestedField.optional(
144, "offset", Types.LongType.get(), "Offset in the file where the content starts");
Types.NestedField SIZE_IN_BYTES =
Types.NestedField.optional(
145,
"size_in_bytes",
Types.LongType.get(),
"Length of a referenced content stored in the file; required if offset is present");
Types.NestedField INLINE_CONTENT =
Types.NestedField.optional(
146, "inline_content", Types.BinaryType.get(), "Serialized bitmap for inline DVs");

/**
* Returns the offset in the file where the deletion vector content starts.
*
* <p>This is used for out-of-line deletion vectors stored in Puffin files.
*/
Long offset();

/**
* Returns the size in bytes of the deletion vector content.
*
* <p>Required if offset is present.
*/
Long sizeInBytes();

/**
* Returns the serialized bitmap for inline deletion vectors.
*
* <p>When present, the deletion vector is stored inline in the manifest rather than in a separate
* Puffin file.
*/
ByteBuffer inlineContent();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mentioned this in my comment below, but I don't think there's much value in combining the inline MDV metadata and fields to track data DVs stored in Puffin. These aren't overlapping, so I'd keep them separate.

Copy link
Contributor Author

@anoopj anoopj Nov 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Data and metadata DVs seemed like similar concepts to me. I can create a separate ManifestDeletionVector.

}
20 changes: 18 additions & 2 deletions api/src/main/java/org/apache/iceberg/FileContent.java
Original file line number Diff line number Diff line change
Expand Up @@ -18,11 +18,27 @@
*/
package org.apache.iceberg;

/** Content type stored in a file, one of DATA, POSITION_DELETES, or EQUALITY_DELETES. */
/**
* Content type stored in a file.
*
* <p>For V1-V3 tables: DATA, POSITION_DELETES, or EQUALITY_DELETES.
*
* <p>For V4 tables: DATA, POSITION_DELETES, EQUALITY_DELETES, DATA_MANIFEST, DELETE_MANIFEST, or
* MANIFEST_DV.
*/
public enum FileContent {
DATA(0),
POSITION_DELETES(1),
EQUALITY_DELETES(2);
EQUALITY_DELETES(2),
/** Data manifest entry (V4+ only) - references data files in a root manifest. */
DATA_MANIFEST(3),
/** Delete manifest entry (V4+ only) - references delete files in a root manifest. */
DELETE_MANIFEST(4),
/**
* Manifest deletion vector entry (V4+ only) - marks entries in a manifest as deleted without
* rewriting the manifest.
*/
MANIFEST_DV(5);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer the option of having the DV located in a field of the data or delete manifest record. That way we don't have to wait to find the DV before processing a manifest file. Not sure what others think here, but since the DV metadata/content is likely going to be different between the Metadata DV (inline) and Data DV (stored in Puffin), I don't see much value in trying to reuse metadata fields for it.

Copy link
Contributor Author

@anoopj anoopj Nov 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That was my preference too, and I advocated for it in our community discussion but this is what we settled on. Our current v4 proposal specifically uses MANIFEST_DV as a separate content type that references manifests via the referenced_file field. We can certainly change it, but want to hear from others.


private final int id;

Expand Down
75 changes: 75 additions & 0 deletions api/src/main/java/org/apache/iceberg/ManifestStats.java
Original file line number Diff line number Diff line change
@@ -0,0 +1,75 @@
/*
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for additional information
* regarding copyright ownership. The ASF licenses this file
* to you under the Apache License, Version 2.0 (the
* "License"); you may not use this file except in compliance
* with the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing,
* software distributed under the License is distributed on an
* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
* under the License.
*/
package org.apache.iceberg;

import org.apache.iceberg.types.Types;

/**
* Statistics for manifest entries in a V4 tracked file.
*
* <p>This encapsulates added/removed/existing files/row counts and min_sequence_number for a
* manifest. This must be defined when the content_type is a manifest (3 or 4), and null otherwise.
*/
public interface ManifestStats {
Types.NestedField ADDED_FILES_COUNT =
Types.NestedField.required(
504, "added_files_count", Types.IntegerType.get(), "Number of files added");
Types.NestedField EXISTING_FILES_COUNT =
Types.NestedField.required(
505, "existing_files_count", Types.IntegerType.get(), "Number of existing files");
Types.NestedField DELETED_FILES_COUNT =
Types.NestedField.required(
506, "deleted_files_count", Types.IntegerType.get(), "Number of deleted files");
Types.NestedField ADDED_ROWS_COUNT =
Types.NestedField.required(
512, "added_rows_count", Types.LongType.get(), "Number of rows in added files");
Types.NestedField EXISTING_ROWS_COUNT =
Types.NestedField.required(
513, "existing_rows_count", Types.LongType.get(), "Number of rows in existing files");
Types.NestedField DELETED_ROWS_COUNT =
Types.NestedField.required(
514, "deleted_rows_count", Types.LongType.get(), "Number of rows in deleted files");
Types.NestedField MIN_SEQUENCE_NUMBER =
Types.NestedField.required(
516,
"min_sequence_number",
Types.LongType.get(),
"Minimum sequence number of files in this manifest");

/** Returns the number of files added by this manifest. */
int addedFilesCount();

/** Returns the number of existing files referenced by this manifest. */
int existingFilesCount();

/** Returns the number of deleted files in this manifest. */
int deletedFilesCount();

/** Returns the number of rows in added files. */
long addedRowsCount();

/** Returns the number of rows in existing files. */
long existingRowsCount();

/** Returns the number of rows in deleted files. */
long deletedRowsCount();

/** Returns the minimum sequence number of files in this manifest. */
long minSequenceNumber();
}
Loading
Loading