[ https://issues.apache.org/jira/browse/KYLIN-2243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16728571#comment-16728571 ]
ASF subversion and git services commented on KYLIN-2243: -------------------------------------------------------- Commit 1af62e46516b7b9a31d3de5a1a7867f9cb51799b in kylin's branch refs/heads/master from liapan [ https://gitbox.apache.org/repos/asf?p=kylin.git;h=1af62e4 ] KYLIN-3738 Edit cube measure may make the decimal type change unexpectly revert KYLIN-2243 8c0c44b887e2caa21b097c2334f8d21c42462e80 > TopN memory estimation is inaccurate in some cases > -------------------------------------------------- > > Key: KYLIN-2243 > URL: https://issues.apache.org/jira/browse/KYLIN-2243 > Project: Kylin > Issue Type: Bug > Reporter: Shaofeng SHI > Assignee: Shaofeng SHI > Priority: Major > Fix For: v2.0.0 > > > TopNCounterSerializer.maxLength() and > TopNCounterSerializer.getStorageBytesEstimate() might be inaccurate, > especially when there are multiple "group by" columns in one TopN measure and > some uses long bytes encoding like "fixed_length:16" > The inaccurate estimation may cause memory issue when using in-mem cubing, > and will cause the estimation on final cube size inaccurate. > The root cause is the data type like "top(100)" doesn't have the info of how > long a key can be. So far it uses a default value 4 which is too small when > the encoding is something like "fixed_length:16". The solution is extending > the expression of data type to "top(100, 16)" to indicate that one key can be > 16 bytes long. If the "scale" is absent, use 4 bytes as default. -- This message was sent by Atlassian JIRA (v7.6.3#76005)