-
Notifications
You must be signed in to change notification settings - Fork 180
Open
Description
I ran into a use case where the current mergeIterator implementation introduces overhead due to its internal heap usage during iterator.Next(), while its ordering and preloading behavior is unnecessary for this access pattern.
In my case:
- iterators are consumed only once
- data comes from MemoryStorage
- ordering and preloading are not needed
Because of that, heap-based merging, ordering, and preloading add cost without improving correctness for this scenario.
It would be useful if mergeIterator could be replaced, similar to how storage implementations are provided via a builder.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels