-
Notifications
You must be signed in to change notification settings - Fork 6.4k
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
Remove compressed block cache #11117
Conversation
@siying has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
@siying has updated the pull request. You must reimport the pull request before landing. |
include/rocksdb/statistics.h
Outdated
@@ -188,12 +188,6 @@ enum Tickers : uint32_t { | |||
// Record the number of calls to GetUpdatesSince. Useful to keep track of | |||
// transaction log iterator refreshes | |||
GET_UPDATES_SINCE_CALLS, | |||
BLOCK_CACHE_COMPRESSED_MISS, // miss in the compressed block cache |
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'm not sure of the consequences of re-numbering existing statistics. @ltamasi
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.
Right, enum values on the C++ and Java sides have to be kept in sync.
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.
Hm, actually on closer inspection, the ids are already out of sync in various ways. Seems like we first diverge at BLOOM_FILTER_FULL_POSITIVE
, which would be 21 == 0x15 in the C++ code but missing from the JNI (where 0x15 is actually PERSISTENT_CACHE_HIT
). Probably stuff got added in the middle at some point.
EDIT: BLOOM_FILTER_FULL_POSITIVE
is actually there further down, with a different id.
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.
Too bad I just spent half an hour changing the numbers and filled the gap...
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.
It definitely would have been nice if the values had been kept in sync but that apparently that ship has sailed; even if we fill this gap, there are pre-existing tickers which have different ids between C++ and Java (e.g. BLOOM_FILTER_FULL_POSITIVE
is 0x63 on the Java side).
There's also this comment in portal.h
; I'm not sure what the original rationale behind exposing TICKER_ENUM_MAX
was (especially since its value is guaranteed to change in the core library whenever a ticker is added) but seems like the convention in the Java bindings is to keep the ids the same across versions:
case ROCKSDB_NAMESPACE::Tickers::TICKER_ENUM_MAX:
// 0x5F was the max value in the initial copy of tickers to Java.
// Since these values are exposed directly to Java clients, we keep
// the value the same forever.
//
// TODO: This particular case seems confusing and unnecessary to pin the
// value since it's meant to be the number of tickers, not an actual
// ticker value. But we aren't yet in a position to fix it since the
// number of tickers doesn't fit in the Java representation (jbyte).
return 0x5F;
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'm more concerned about if dependent internal code is tied to the ordinal numbers. Can take discussion to https://www.internalfb.com/diff/D42700164
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.
Just did some digging in this area while working on removing some (other) stats - I'm fairly confident renumbering on the C++ side is safe because it has (organically) happened many times over the years as people added new tickers near related existing ones (as opposed to the end of the list). The Java bindings zag where the core library zigs though.
/** | ||
* Miss in the compressed block cache. | ||
*/ | ||
BLOCK_CACHE_COMPRESSED_MISS((byte) 0x42), |
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.
Probably wrong for new numbers
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 don't think it would be wrong, as in portal.h they are just hard coded in the same way. I updated the PR and removed the gap anyway to be safer.
@@ -539,12 +524,6 @@ Status CheckCacheOptionCompatibility(const BlockBasedTableOptions& bbto) { | |||
->Insert(sentinel_key.AsSlice(), &kRegularBlockCacheMarker, &kHelper, 1) | |||
.PermitUncheckedError(); | |||
} | |||
if (bbto.block_cache_compressed) { | |||
bbto.block_cache_compressed | |||
->Insert(sentinel_key.AsSlice(), &kCompressedBlockCacheMarker, &kHelper, |
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.
A bit more to remove here, kCompressedBlockCacheMarker and related code below
858d36b
to
bc7f338
Compare
@siying has updated the pull request. You must reimport the pull request before landing. |
1 similar comment
@siying has updated the pull request. You must reimport the pull request before landing. |
Can you re-import? GitHub won't show me what has changed since my review, presumably because of the force-push. Thanks |
@siying has updated the pull request. You must reimport the pull request before landing. |
@siying has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
I just reimported. |
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'm not sure about downstream breakage if we re-number stats, but otherwise LGTM
@@ -232,8 +232,6 @@ static std::unordered_map<std::string, OptionTypeInfo> | |||
block_based_table_type_info = { | |||
#ifndef ROCKSDB_LITE | |||
/* currently not supported | |||
std::shared_ptr<Cache> block_cache = nullptr; |
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.
Please keep this line, to remind us that block_cache is not dynamically configurable
One thing you might consider is separating out the stat removals & Java numbering updates into another PR, in case we need an easy revert path. |
Summary: Compressed block cache is replaced by compressed secondary cache. Remove the feature. Test Plan: See CI passes
8d82fd2
to
58f532e
Compare
@siying has updated the pull request. You must reimport the pull request before landing. |
@siying has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
Add back to statistics and the comment line deleted by mistake. |
This pull request has been merged in 2800aa0. |
Summary:
Compressed block cache is replaced by compressed secondary cache. Remove the feature.
Test Plan: See CI passes