Details
-
Improvement
-
Resolution: Unresolved
-
Major
-
7.0.4
-
1
Description
(As highlighted by a recent CBSE)
If running in full-eviction and Bloom filters are either not available (e.g. MB-40172), or user is accessing a key which is missing the filter, then we attempt to bgFetch the item from disk. If the bgfetch finds the item doesn't exist, we discard from the HashTable as soon as the response has been generated for the user - e.g.:
cb::EngineErrorItemPair EventuallyPersistentEngine::get(
|
CookieIface& cookie,
|
const DocKey& key, |
Vbid vbucket,
|
DocStateFilter documentStateFilter) {
|
auto options = static_cast<get_options_t>( |
QUEUE_BG_FETCH | HONOR_STATES | TRACK_REFERENCE | DELETE_TEMP |
|
HIDE_LOCKED_CAS | TRACK_STATISTICS);
|
...
|
GetValue VBucket::getInternal(...) {
|
...
|
// If SV is otherwise a temp non-existent (i.e. a marker added after a |
// BgFetch to note that no such item exists) or temp deleted, then we |
// should cleanup the SV (if requested) before returning ENOENT (so we |
// don't keep temp items in HT). |
if (v->isTempDeletedItem() || v->isTempNonExistentItem()) { |
if (options & DELETE_TEMP) { |
deleteStoredValue(res.lock, *v);
|
}
|
return {}; |
}
|
While there is merit in keeping the HashTable free of items we "shouldn't need" again - reducing how often the ItemPager must run to clean it up - in this scenario we are discarding useful information - another request for the same key in the future would have to go back to disk again (and again, and again...); when we could avoid that by keeping the temp_non_existent item in the HashTable.
Attachments
Issue Links
- relates to
-
-
- Open
-