Optimize the prefix performance of RocksDB iterator after delete range

[luyade]

What type of PR is this?

• bug
• feature
• enhancement

What problem(s) does this PR solve?

Issue(s) number:

#5524

Description:

How do you solve it?

Special notes for your reviewer, ex. impact of this fix, design document, etc:

Checklist:

Tests:

• Unit test(positive and negative cases)
• Function test
• Performance test
• N/A

Affects:

• Documentation affected (Please add the label if documentation needs to be modified.)
• Incompatibility (If it breaks the compatibility, please describe it and add the label.）
• If it's needed to cherry-pick (If cherry-pick to some branches is required, please label the destination version(s).)
• Performance impacted: Consumes more CPU/Memory

Release notes:

Please confirm whether to be reflected in release notes and how to describe:

ex. Fixed the bug .....

[wenhaocs]

Good job. Thanks for the contribution.

[wenhaocs]

Since it's temporary, I prefer keeping its lifetime temp as well, that is, not setting as protected/private variable.

[luyade]

iterateUpperBoundKey_ is not really temporary. This string should be valid during the whole lifetime of this iterator. Otherwise, if the string got destroyed before iterator, the iterate_upper_bound of rocksdb::ReadOptions will become invalid, which will then result in crash.

[pengweisong]

then the field iterateUpperBound_ is no needed, you could construct rocksdb::Slice from upperBoundKey_ every time when needed. Since rocksdb::Slice is an string view, and really lightweight.

[luyade]

updated. We passed a pointer to ReadOptions and we should make sure the pointer valid before the iterator is destructed, so the Slice also should not be a local temporary variable.

[pengweisong]

Good job, thanks for contribution.

[pengweisong]

then the field iterateUpperBound_ is no needed, you could construct rocksdb::Slice from upperBoundKey_ every time when needed. Since rocksdb::Slice is an string view, and really lightweight.

[pengweisong]

Good job