[
https://issues.apache.org/jira/browse/KYLIN-3444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifei Wu updated KYLIN-3444:
----------------------------
Description:
In Kylin，there could be some unexpected results in Choosing Realization.
For example, there are 2 models in the same project, called A and B, and each
of it owns a Cube and a TableIndex. just like this,
project
/ \
model(A) model(B)
/ \ / \
CUBE(a) TableIndex(a) CUBE(b) TableIndex(b)
Nowadays, the algorithm is designed to choose the matched models, and then get
into the model and select the proper and cheapest realizations(cube or
TableIndex here). However, it can cause some confusing issue, for example, when
running a query with agg functions (like "SELECT SUM(aa) from A GROUP BY bb")
and *the CUBE(a) cannot serve this query but CUBE(b) can*, it should be hit the
CUBE(b) rather than TableIndex(a) in the case, for there are aggregations, it
utilize the cube
was:
In Kylin，there could be some unexpected results in Choosing Realization.
For example, there are 2 models in the same project, called A and B, and each
of it owns a Cube and a TableIndex. just like this,
project
/ \
model(A) model(B)
/ \ / \
CUBE(a) TableIndex(a) CUBE(b) TableIndex(b)
Nowadays, the algorithm is designed to choose the matched models, and then get
into the model and select the proper and cheapest realizations(cube or
TableIndex here). However, it can cause some confusing issue, for example, when
running a query with agg functions (like "SELECT SUM(aa) from A GROUP BY bb")
and *the CUBE(a) cannot serve this query but CUBE(b) can*, it should be hit the
CUBE(b) rather than TableIndex(a) in the case, for there are aggregations, it
use the Cube
> support more reasonable Realization Chooser method in accordance with
> specific SQL
> ----------------------------------------------------------------------------------
>
> Key: KYLIN-3444
> URL: https://issues.apache.org/jira/browse/KYLIN-3444
> Project: Kylin
> Issue Type: Improvement
> Reporter: Yifei Wu
> Assignee: Yifei Wu
> Priority: Major
>
> In Kylin，there could be some unexpected results in Choosing Realization.
> For example, there are 2 models in the same project, called A and B, and each
> of it owns a Cube and a TableIndex. just like this,
> project
> / \
> model(A) model(B)
> / \ / \
> CUBE(a) TableIndex(a) CUBE(b) TableIndex(b)
> Nowadays, the algorithm is designed to choose the matched models, and then
> get into the model and select the proper and cheapest realizations(cube or
> TableIndex here). However, it can cause some confusing issue, for example,
> when running a query with agg functions (like "SELECT SUM(aa) from A GROUP BY
> bb") and *the CUBE(a) cannot serve this query but CUBE(b) can*, it should be
> hit the CUBE(b) rather than TableIndex(a) in the case, for there are
> aggregations, it utilize the cube
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
