[
https://issues.apache.org/jira/browse/LENS-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14506723#comment-14506723
]
Amareshwari Sriramadasu commented on LENS-414:
----------------------------------------------
Just noticed the following :
{noformat}
if (!lightFactFirst) {
rewriters.add(new LightestFactResolver(conf));
}
// Phase 3: resolve dimension tables and partitions.
rewriters.add(storageTableResolver);
// Check for candidate tables using de-normalized columns
rewriters.add(denormResolver);
rewriters.add(new LeastPartitionResolver(conf));
if (!lightFactFirst) {
rewriters.add(new LightestFactResolver(conf));
}
{noformat}
LightestFactResolver is getting added twice when lightest first config is off -
once before and once after LeastPartitionResolver. Needs to be added only once.
We can have LightestFactResolver before LeastPartitionResolver - that says "if
two facts have the same least weight, then the fact with least number of time
partitions queried will be picked". This will be useful, if users did not set
fact weights.
bq. The number of partitions being calculated is not the correct number after
LENS-281. It is only number of time values now instead of partitions.
This seems fine, as the less number of time values actually represent the
rollups on time - when we have MaxCoveringFactResolver
> LeastPartitionResolver broken after partition timeline cache?
> -------------------------------------------------------------
>
> Key: LENS-414
> URL: https://issues.apache.org/jira/browse/LENS-414
> Project: Apache Lens
> Issue Type: Bug
> Components: cube
> Reporter: Amareshwari Sriramadasu
> Assignee: Rajat Khandelwal
> Fix For: 2.2
>
>
> The number of partitions being calculated is not the correct number after
> LENS-281. It is only number of time values now instead of partitions.
> We might have to change LeastPartitionResolver accordingly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
