-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make a static pinning decision based on the last level with data (not bottommost level) (#626) #684
Make a static pinning decision based on the last level with data (not bottommost level) (#626) #684
Conversation
db/column_family.cc
Outdated
return current_->storage_info(); | ||
} | ||
|
||
int ColumnFamilyData::IsLastLevelWithData(int level) const { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bool?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
db/column_family.cc
Outdated
int last_level_with_data = vstorage->num_non_empty_levels() - 1; | ||
|
||
auto is_last_level_with_data = false; | ||
if ((level > 0) and (level == last_level_with_data)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"&&" rather than "and" ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
db/table_cache.cc
Outdated
@@ -68,15 +68,17 @@ TableCache::TableCache(const ImmutableOptions& ioptions, | |||
const FileOptions* file_options, Cache* const cache, | |||
BlockCacheTracer* const block_cache_tracer, | |||
const std::shared_ptr<IOTracer>& io_tracer, | |||
const std::string& db_session_id) | |||
const std::string& db_session_id, | |||
IsLastLevelWithDataFunc is_last_leve_with_data_func) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"is_last_level_with_data_func" (not leve_)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
TablePinningOptions(int _level, bool _is_last_level_with_data, | ||
size_t _file_size, size_t _max_file_size_for_l0_meta_pin) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason not to have both "last level with data" and "bottom"? I know the current use case does not seem to care about the distinction but I am wondering if it could be important in the future (or if this use case proves to be incomplete).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hilik's intention is clearly to decide based on the last level with data.
If we ever do find a use case for the bottom flag as well, we will add it. I really see no need to have it just in case.
@mrambacher I have pushed a commit addressing the issues you have raised. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved with minor comments/suggestions
ASSERT_GT(total_num_pinned_, 0U); | ||
--total_num_pinned_; | ||
|
||
ASSERT_GE(usage_, pinned->size); | ||
usage_ -= pinned->size; | ||
|
||
if (pinned->is_last_level_with_data) { | ||
ASSERT_GT(num_pinned_last_level_with_data_, 0U); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These should probably be EXPECT_xx rather than ASSERT_xx ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why shouldn't it be ASSERT_xx?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why shouldn't it be ASSERT_xx?
In my experience, ASSERT should be when the top-level method is failing whereas EXPECT should be when the failure is a long way from the code.
I would suggest you run an experiment where you hit one of these inner ASSERT statements and observe how the test fails. I often find those deep ASSERT messages hard to trace
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, however, the guideline I am following when choosing EXPECT_* rather than ASSERT_* is the following:
"The rule of thumb is to use EXPECT_* when you want the test to continue to reveal more errors after the assertion failure, and use ASSERT_* when continuing after failure doesn’t make sense"
(From the "GoogleTest Primer" on github, for some reason the url fails to work)
db/table_cache.h
Outdated
@@ -49,12 +50,16 @@ class HistogramImpl; | |||
// cache, lookup is very fast. The row cache is obtained from | |||
// ioptions.row_cache | |||
class TableCache { | |||
public: | |||
using IsLastLevelWithDataFunc = std::function<int(int level)>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The function should return a bool
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
4c3c246
to
218d050
Compare
@mrambacher Thanks for the review. |
@udi-speedb , the CI seems to have failed but the force push removed that commit from this PRs history.. please refrain from force pushing after approval or rerun the CI if you do.
|
|
@Yuval-Ariel As I have already noted. If a forced push introduces code changes (not squash / commit message changes only), the CI should automatically restart and merge should be blocked as long as it doesn't pass the CI |
… bottommost level) (#626)
218d050
to
6784aad
Compare
@Yuval-Ariel - Manual run of the CI passed |
I see. Well, It's always good to know that our main branch passes the CI. As for performance, you are correct. Thanks |
@erez-speedb Please run performace tests on this branch. Thanks |
@erez-speedb - Please update on the results of the performance testing and if we may merge this pr or do something else. Thanks |
No description provided.