[
https://issues.apache.org/jira/browse/KYLIN-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
hongbin ma updated KYLIN-1601:
------------------------------
Issue Type: Improvement (was: Bug)
> Need not to shrink scan cache when hbase rows can be large
> ----------------------------------------------------------
>
> Key: KYLIN-1601
> URL: https://issues.apache.org/jira/browse/KYLIN-1601
> Project: Kylin
> Issue Type: Improvement
> Reporter: hongbin ma
> Assignee: hongbin ma
>
> to control memory usage we used to shrink scan cache when hbase rows can be
> large
> if (RowValueDecoder.hasMemHungryMeasures(rowValueDecoders)) {
> scan.setCaching(scan.getCaching() / 10);
> }
> however since now scan.setCaching is accompanied by scan.setMaxResultSize,
> it's no longer necessary because the size limit will come first before cache
> rows limit.
> quote from
> http://www.cloudera.com/documentation/enterprise/5-2-x/topics/admin_hbase_scanning.htm:
> "When you use setCaching and setMaxResultSize together, single server
> requests are limited by either number of rows or maximum result size,
> whichever limit comes first."
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
