snazy opened a new issue, #2365:
URL: https://github.com/apache/polaris/issues/2365

   ### Describe the bug
   
   The implemented logic to prune Iceberg tables puts a huge amount of pressure 
to the Java heap.
   
   The logic roughly works like this:
   * Input parameter: pointer to a table metadata
   * Read table metadata
   * Read manifest lists of all snapshots
   * Read all manifest files of all manifest lists
   * Create a new task entity for each manifest file
   
   Each manifest file can become really big, many MB of binary data.
   
   The [base64 encoded full binary Iceberg manifest 
files](https://github.com/apache/polaris/blob/c9efc6c1af202686945efe2e19125e8f116a0206/runtime/service/src/main/java/org/apache/polaris/service/task/TableCleanupTaskHandler.java#L194)
 are included in the task entities, which are [consumed 
here](https://github.com/apache/polaris/blob/c9efc6c1af202686945efe2e19125e8f116a0206/runtime/service/src/main/java/org/apache/polaris/service/task/ManifestFileCleanupTaskHandler.java#L67).
   
   Although some Java stream handling is being used, all manifest-files of the 
table to purge are [materialized at once on the Java 
heap](https://github.com/apache/polaris/blob/c9efc6c1af202686945efe2e19125e8f116a0206/runtime/service/src/main/java/org/apache/polaris/service/task/TableCleanupTaskHandler.java#L111-L130).
   
   Even worse, the base64 encoded data is added to a JSON serialized object, 
which is added to a properties bag, which is in turn JSON serialized. Since 
JSON re-serializations of that property bag are "normal", the total heap 
pressure is bigger than the sum of all base64 serialized manifest-files.
   
   ### To Reproduce
   
   _No response_
   
   ### Actual Behavior
   
   _No response_
   
   ### Expected Behavior
   
   _No response_
   
   ### Additional context
   
   _No response_
   
   ### System information
   
   _No response_


-- 
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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to