amogh-jahagirdar commented on code in PR #12670:
URL: https://github.com/apache/iceberg/pull/12670#discussion_r2017577925
##########
core/src/main/java/org/apache/iceberg/MetadataUpdate.java:
##########
@@ -328,20 +328,20 @@ public void applyTo(TableMetadata.Builder
metadataBuilder) {
}
}
- class RemoveSnapshot implements MetadataUpdate {
- private final long snapshotId;
+ class RemoveSnapshots implements MetadataUpdate {
+ private final Set<Long> snapshotIds;
- public RemoveSnapshot(long snapshotId) {
- this.snapshotId = snapshotId;
+ public RemoveSnapshots(Set<Long> snapshotIds) {
+ this.snapshotIds = snapshotIds;
}
- public long snapshotId() {
- return snapshotId;
+ public Set<Long> snapshotIds() {
+ return snapshotIds;
}
@Override
public void applyTo(TableMetadata.Builder metadataBuilder) {
- metadataBuilder.removeSnapshots(ImmutableSet.of(snapshotId));
+ metadataBuilder.removeSnapshots(snapshotIds);
}
Review Comment:
We should leave`RemoveSnapshot` update as is since this is still a valid
update type in the protocol. I think the solution should involve some sort of
buffering of the snapshots to remove instead of eagerly rewriting (it's the
eager rewriting of the current snapshots in the builder that leads to the n^2
behavior). Only at the end, once all the snapshots to remove have been
accumulated, would we want to go ahead and rewrite. Let me take a deeper look
and get back with a concrete solution
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org
For additional commands, e-mail: issues-h...@iceberg.apache.org
