Skip to content

Core: Skip unnecessary metadata refresh after merge append #14709

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
gaborkaszab wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Core: Skip unnecessary metadata refresh after merge append #14709

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 6 additions & 1 deletion core/src/main/java/org/apache/iceberg/MergingSnapshotProducer.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -968,7 +968,12 @@ public List<ManifestFile> apply(TableMetadata base, Snapshot snapshot) {
@Override
public Object updateEvent() {
long snapshotId = snapshotId();
Snapshot justSaved = ops().refresh().snapshot(snapshotId);

Snapshot justSaved = ops().current().snapshot(snapshotId);
Copy link
Contributor

@flyrain flyrain Dec 10, 2025

Choose a reason for hiding this comment

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

Thanks a lot for the changes, @gaborkaszab ! Should we check if ops is an instance of RESTTableOperations to ensure this is REST operation?

Copy link
Collaborator Author

@gaborkaszab gaborkaszab Dec 10, 2025

Choose a reason for hiding this comment

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

That is the other approach I was considering. I didn't want (Merging)SnapshotProducer to know about what is the underlying TableOps implementation and I preferred this more general approach. Basically, instead of asking "is this REST ops?" I ask "do we have this snapshot" that seemed more robust and general.
WDYT @flyrain ?

Copy link
Contributor

@flyrain flyrain Dec 13, 2025

Choose a reason for hiding this comment

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

Thanks for the explanation. To be clear, I'm all for a generic way instead of dedicating to one type of table operation. My confusion and concern came from the PR description as the following:

With RESTTableOperations it's not required to perform a refresh after committing a merge append because the commit already refreshes table metadata.

Copy link
Collaborator Author

@gaborkaszab gaborkaszab Dec 15, 2025

Choose a reason for hiding this comment

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

Thanks for pointing that out, @flyrain ! I updated the description to be a bit more generic, and use RESTTableOperations as an example.

if (justSaved == null) {
justSaved = ops().refresh().snapshot(snapshotId);
}

long sequenceNumber = TableMetadata.INVALID_SEQUENCE_NUMBER;
Map<String, String> summary;
if (justSaved == null) {
Expand Down
5 changes: 5 additions & 0 deletions core/src/test/java/org/apache/iceberg/catalog/CatalogTests.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3271,6 +3271,11 @@ public void testCatalogWithCustomMetricsReporter() throws IOException {
assertThat(CustomMetricsReporter.SCAN_COUNTER.get()).isEqualTo(1);
// reset counter in case subclasses run this test multiple times
CustomMetricsReporter.SCAN_COUNTER.set(0);

// append file through MergeAppend and check and reset counter
table.newAppend().appendFile(FILE_A).commit();
assertThat(CustomMetricsReporter.COMMIT_COUNTER.get()).isEqualTo(1);
CustomMetricsReporter.COMMIT_COUNTER.set(0);
Comment on lines +3276 to +3278
Copy link
Contributor

@amogh-jahagirdar amogh-jahagirdar Jan 20, 2026

Choose a reason for hiding this comment

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

Sorry not entirely following, what additional behavior related to this change are we trying test here? This just looks like it verifies the commit is performed and the metrics after that.

}

public static class CustomMetricsReporter implements MetricsReporter {
Expand Down
17 changes: 17 additions & 0 deletions core/src/test/java/org/apache/iceberg/rest/TestRESTCatalog.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4326,6 +4326,23 @@ public void testTableCacheAgeDoesNotRefreshesAfterAccess() {
.isEqualTo(HALF_OF_TABLE_EXPIRATION);
}

@Test
public void testNumLoadTableCallsForMergeAppend() {
RESTCatalogAdapter adapter = Mockito.spy(new RESTCatalogAdapter(backendCatalog));

RESTCatalog catalog = catalog(adapter);

catalog.createNamespace(TABLE.namespace());

BaseTable table = (BaseTable) catalog.createTable(TABLE, SCHEMA);

table.newAppend().appendFile(FILE_A).commit();
Copy link
Contributor

@amogh-jahagirdar amogh-jahagirdar Jan 20, 2026

Choose a reason for hiding this comment

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

Before the commit, we may want to extract out the CreateSnapshotEvent and assert it's what we expect, since that's the part we're changing?


// loadTable is executed once
Mockito.verify(adapter)
.execute(reqMatcher(HTTPMethod.GET, RESOURCE_PATHS.table(TABLE)), any(), any(), any());
}

private RESTCatalog catalog(RESTCatalogAdapter adapter) {
RESTCatalog catalog =
new RESTCatalog(SessionCatalog.SessionContext.createEmpty(), (config) -> adapter);
Expand Down