[
https://issues.apache.org/jira/browse/HDDS-15894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18099206#comment-18099206
]
Chi-Hsuan Huang commented on HDDS-15894:
----------------------------------------
I investigated the current call paths.
Since HDDS-13553, all three callers use a new, empty staged DB, so
truncateTable(..) normally has nothing to delete.
That said, I think it is still worth improving because its O(n) point deletes
could become expensive for any future non-staged caller.
I plan to fix it with Method 2 (deleteRange): find the first and last keys,
delete [first, last), then delete the last key separately. This keeps the
change local to ReconDBProvider and avoids the column-family lifecycle issues
of drop-and-recreate. I'll open a PR soon.
> ReconDBProvider.truncateTable(..) is inefficient
> ------------------------------------------------
>
> Key: HDDS-15894
> URL: https://issues.apache.org/jira/browse/HDDS-15894
> Project: Apache Ozone
> Issue Type: Improvement
> Components: Ozone Recon
> Reporter: Tsz-wo Sze
> Assignee: Chi-Hsuan Huang
> Priority: Major
> Attachments: image-2026-07-17-11-49-56-671.png
>
>
> The truncateTable(..) method in ReconDBProvider
> - indeed is clearing the entire table but not truncating it.
> - It uses an iterator to delete the entry one by one, which is very slow.
> Better ways suggested by Google are either:
> - Method 1: Drop and Recreate (Fastest)
> - Method 2: Use deleteRange (For Default or Inline Clearing)
> See below for more details.
> !image-2026-07-17-11-49-56-671.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
