The SQL statement DROP TABLE <table_name> for Iceberg tables, where the associated table metadata has already been deleted from the S3 storage, is taking significantly longer time than anticipated. The delay in dropping these Iceberg tables, where the metadata has already been deleted from the S3 storage, is due to multiple retries during the process of checking if the table still exists.

Environment

• Presto version used: v0.289
• Storage (HDFS/S3/GCS..): S3
• Data source and connector used: Iceberg

Expected Behavior

If the metadata for the table is missing, it should skip retry, when the FileNotFoundException is thrown. It should be quickly concluded that the table no longer exists and complete the drop operation without excessive retry delays.

Current Behavior

Now even if the FileNotFoundException is thrown around 20 retries are happening, before the table is getting dropped.

Possible Solution

Avoid retries once a FileNotFoundException is thrown.

PR: #23510

Steps to Reproduce

1. Connect Presto to an S3 storage through an Iceberg connector.
2. Create a schema, and within the schema create a table.
3. Now, delete the metadata and the bucket.
4. Try dropping the associated the table.

Context

Drop table operation is not completing within the expected timeframe, causing potential disruptions or delays in the workflow.