[
https://issues.apache.org/jira/browse/KUDU-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17894304#comment-17894304
]
ASF subversion and git services commented on KUDU-613:
------------------------------------------------------
Commit b70a1528c6c3d17d4388cdd64027558b74873243 in kudu's branch
refs/heads/branch-1.18.x from Mahesh Reddy
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=b70a1528c ]
KUDU-613: Fix minor metrics related bug
When upserting in the protected segment, the state
of the handle isn't updated properly (the variable
in_protected_segment). This variable is used later
when releasing the handle to determine which segment's
metrics to update. This patch fixes this bug and adds
appropriate test coverage to verify the right metrics
are being updated.
Change-Id: I0d2fd44169e1abe642c11e16e4b87aaa971b2d88
Reviewed-on: http://gerrit.cloudera.org:8080/21956
Tested-by: Alexey Serbin <ale...@apache.org>
Reviewed-by: Alexey Serbin <ale...@apache.org>
(cherry picked from commit ffc1b11f6b54f0e799146f2e444c5b001827dd31)
Reviewed-on: http://gerrit.cloudera.org:8080/21992
> Scan-resistant cache replacement algorithm for the block cache
> --------------------------------------------------------------
>
> Key: KUDU-613
> URL: https://issues.apache.org/jira/browse/KUDU-613
> Project: Kudu
> Issue Type: Improvement
> Components: perf
> Affects Versions: M4.5
> Reporter: Andrew Wang
> Assignee: Mahesh Reddy
> Priority: Major
> Labels: performance, roadmap-candidate
>
> The block cache currently uses LRU, which is vulnerable to large scan
> workloads. It'd be good to implement something like 2Q.
> ARC (patent encumbered, but good for ideas):
> https://www.usenix.org/conference/fast-03/arc-self-tuning-low-overhead-replacement-cache
> HBase (2Q like):
> https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/LruBlockCache.java
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
