[jira] [Updated] (CALCITE-2187) Fix build issue caused by CALCITE-2170
[
https://issues.apache.org/jira/browse/CALCITE-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesus Camacho Rodriguez updated CALCITE-2187:
-
Summary: Fix build issue caused by CALCITE-2170 (was: Fix Build issue
caused by CALCITE-2170)
> Fix build issue caused by CALCITE-2170
> --
>
> Key: CALCITE-2187
> URL: https://issues.apache.org/jira/browse/CALCITE-2187
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Reporter: slim bouguerra
>Assignee: slim bouguerra
>Priority: Major
> Fix For: 1.16.0
>
>
> CALCITE-2170 introduced the use of Guava Function not existing in 14 Version
> that cause the build to fail when \{code}guava.version=14.0.1\{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CALCITE-2187) Fix Build issue caused by CALCITE-2170
[
https://issues.apache.org/jira/browse/CALCITE-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesus Camacho Rodriguez resolved CALCITE-2187.
--
Resolution: Fixed
Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/6b1d247 , thanks
[~bslim]
> Fix Build issue caused by CALCITE-2170
> --
>
> Key: CALCITE-2187
> URL: https://issues.apache.org/jira/browse/CALCITE-2187
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Reporter: slim bouguerra
>Assignee: slim bouguerra
>Priority: Major
> Fix For: 1.16.0
>
>
> CALCITE-2170 introduced the use of Guava Function not existing in 14 Version
> that cause the build to fail when \{code}guava.version=14.0.1\{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2187) Fix Build issue caused by CALCITE-2170
[
https://issues.apache.org/jira/browse/CALCITE-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16368392#comment-16368392
]
slim bouguerra edited comment on CALCITE-2187 at 2/17/18 10:25 PM:
---
[~julianhyde] please check the fix, I have tested with
{code} mvn clean install -P it -Duser.timezone=Europe/Moscow
-Dguava.version=14.0.1 -DskipTests {code}
Did not know that we are running builds with Old Guava.
FYI if Hive is the reason to keep building with guava 14 then we can drop it
since Hive moved to Guava 19 as per
https://issues.apache.org/jira/browse/HIVE-15393
was (Author: bslim):
[~julianhyde] please check the fix, I have tested with \{code} mvn clean
install -P it -Duser.timezone=Europe/Moscow -Dguava.version=14.0.1 -DskipTests
\{code}. Did not know that we are running builds with Old Guava.
FYI if Hive is the reason to keep building with guava 14 then we can drop it
since Hive moved to Guava 19 as per
https://issues.apache.org/jira/browse/HIVE-15393
> Fix Build issue caused by CALCITE-2170
> --
>
> Key: CALCITE-2187
> URL: https://issues.apache.org/jira/browse/CALCITE-2187
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Reporter: slim bouguerra
>Assignee: slim bouguerra
>Priority: Major
> Fix For: 1.16.0
>
>
> CALCITE-2170 introduced the use of Guava Function not existing in 14 Version
> that cause the build to fail when \{code}guava.version=14.0.1\{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2187) Fix Build issue caused by CALCITE-2170
[
https://issues.apache.org/jira/browse/CALCITE-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16368392#comment-16368392
]
slim bouguerra commented on CALCITE-2187:
-
[~julianhyde] please check the fix, I have tested with \{code} mvn clean
install -P it -Duser.timezone=Europe/Moscow -Dguava.version=14.0.1 -DskipTests
\{code}. Did not know that we are running builds with Old Guava.
FYI if Hive is the reason to keep building with guava 14 then we can drop it
since Hive moved to Guava 19 as per
https://issues.apache.org/jira/browse/HIVE-15393
> Fix Build issue caused by CALCITE-2170
> --
>
> Key: CALCITE-2187
> URL: https://issues.apache.org/jira/browse/CALCITE-2187
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Reporter: slim bouguerra
>Assignee: slim bouguerra
>Priority: Major
> Fix For: 1.16.0
>
>
> CALCITE-2170 introduced the use of Guava Function not existing in 14 Version
> that cause the build to fail when \{code}guava.version=14.0.1\{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2187) Fix Build issue caused by CALCITE-2170
[
https://issues.apache.org/jira/browse/CALCITE-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16368387#comment-16368387
]
slim bouguerra commented on CALCITE-2187:
-
https://github.com/apache/calcite/pull/631
> Fix Build issue caused by CALCITE-2170
> --
>
> Key: CALCITE-2187
> URL: https://issues.apache.org/jira/browse/CALCITE-2187
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Reporter: slim bouguerra
>Assignee: slim bouguerra
>Priority: Major
> Fix For: 1.16.0
>
>
> CALCITE-2170 introduced the use of Guava Function not existing in 14 Version
> that cause the build to fail when \{code}guava.version=14.0.1\{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2187) Fix Build issue caused by CALCITE-2170
slim bouguerra created CALCITE-2187:
---
Summary: Fix Build issue caused by CALCITE-2170
Key: CALCITE-2187
URL: https://issues.apache.org/jira/browse/CALCITE-2187
Project: Calcite
Issue Type: Bug
Components: druid
Reporter: slim bouguerra
Assignee: slim bouguerra
Fix For: 1.16.0
CALCITE-2170 introduced the use of Guava Function not existing in 14 Version
that cause the build to fail when \{code}guava.version=14.0.1\{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2186) Implement ScalaTypeFactory
[ https://issues.apache.org/jira/browse/CALCITE-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16368338#comment-16368338 ] Julian Hyde commented on CALCITE-2186: -- Or possibly add this functionality to JavaTypeFactory. Such patterns will never occur in Java programs, only Scala, but that shouldn't concern the type factory. > Implement ScalaTypeFactory > -- > > Key: CALCITE-2186 > URL: https://issues.apache.org/jira/browse/CALCITE-2186 > Project: Calcite > Issue Type: New Feature >Reporter: Srdan Srepfler >Assignee: Julian Hyde >Priority: Minor > > It would be useful to have a ScalaTypeFactory which would work out of the box > for case class parameters list. > Possibly it could be extensible to support via extensions with some common > Scala record patterns like HList's, tuples and similar. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2179) General improvements for materialized view rewriting rule
[
https://issues.apache.org/jira/browse/CALCITE-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16366375#comment-16366375
]
Jesus Camacho Rodriguez edited comment on CALCITE-2179 at 2/17/18 6:28 PM:
---
[~julianhyde], thanks for the feedback.
bq. If join orderings are a problem, have you considered using lattices?
Queries are rewritten to use the virtual "star" table underlying the lattice
and you avoid the combinatorial problem of matching join orders.
This should not be a problem as the rewriting will work at multiple levels in
the operator tree, it is just whether we want to enable/disable that feature.
bq. Your example query uses date constants but I presume you intend this to
work for date-time columns or expressions.
That is correct, it is just an example, but it will work on all date-time
columns.
bq. Rolling up FLOOR seems to be safe because FLOOR is monotonic (or, more
precisely, FLOOR(t TO timeUnit) is monotonic in t, for any given timeUnit). Are
these optimizations applicable to other monotonic operations, for example
division by a positive constant (x / 10 is monotonic in x)?
That is very useful, thanks. You are correct, currently I only implemented it
for FLOOR function but I will study extending the logic to work with monotonic
operations before updating the patch.
was (Author: jcamachorodriguez):
[~julianhyde], thanks for the feedback.
bq. If join orderings are a problem, have you considered using lattices?
Queries are rewritten to use the virtual "star" table underlying the lattice
and you avoid the combinatorial problem of matching join orders.
This should not be a problem as the rewriting will work at multiple levels in
the operator tree, it is just whether we want to enable/disable that feature.
bq. Your example query uses date constants but I presume you intend this to
work for date-time columns or expressions.
That is correct, it is just an example, but it will work on all date-time
columns.
bq. Rolling up FLOOR seems to be safe because FLOOR is monotonic (or, more
precisely, FLOOR(t TO timeUnit) is monotonic in t, for any given timeUnit). Are
these optimizations applicable to other monotonic operations, for example
division by a positive constant (x / 10 is monotonic in x)?
That is very useful, thanks. You are correct, currently I only implemented it
for FLOOR function but I will extend the logic to work with monotonic
operations before updating the patch (it should not be too difficult).
> General improvements for materialized view rewriting rule
> -
>
> Key: CALCITE-2179
> URL: https://issues.apache.org/jira/browse/CALCITE-2179
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
>Priority: Major
> Fix For: 1.16.0
>
>
> This issue is for extending {{AbstractMaterializedViewRule}} rule:
> - Support for rolling up date nodes. For instance, rewrite in the following
> case:
> {code}
> Materialization:
> select "empid", floor(cast('1997-01-20' as timestamp) to month), count(*) + 1
> as c, sum("empid") as s
> from "emps" group by "empid", floor(cast('1997-01-20' as timestamp) to month);
> Query:
> select floor(cast('1997-01-20' as timestamp) to year), sum("empid") as s
> from "emps" group by floor(cast('1997-01-20' as timestamp) to year);
> {code}
> - Add flag to enable/disable fast bail out for joins. By default it is true,
> and thus, we were only creating the rewriting in the minimal subtree of plan
> operators. For instance:
> {code}
> View: (A JOIN B) JOIN C
> Query: (((A JOIN B) JOIN D) JOIN C) JOIN E
> {code}
> We produce it at:
> {code}
> ((A JOIN B) JOIN D) JOIN C
> {code}
> But not at:
> {code}
> (((A JOIN B) JOIN D) JOIN C) JOIN E
> {code}
> This is important when the rule is used with the Volcano planner together
> with other rules, e.g. join reordering, as it prevents that the search space
> grows unnecessarily. However, if we use the rewriting rule in isolation, fast
> bail out can lead to missing rewriting opportunities (e.g. for bushy join
> trees).
> - Possibility to provide a HepProgram to optimize query branch in union
> rewritings. Note that when we produce a partial rewriting with a Union, the
> branch that will execute the (partial) query can be fully rewritten so we can
> add the compensation predicate. (We cannot do the same for views because the
> expression might not be computable if the needed subexpressions are not
> available in the view output). If we use Volcano with a determined set of
> rules, this might not be needed, hence providing this program is optional.
> - Multiple small fixes discovered while testing.
--
This message was sent by Atlassian JIRA
[jira] [Commented] (CALCITE-2179) General improvements for materialized view rewriting rule
[
https://issues.apache.org/jira/browse/CALCITE-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16368309#comment-16368309
]
Jesus Camacho Rodriguez commented on CALCITE-2179:
--
https://github.com/apache/calcite/pull/630
I included tests for rewritings on no constant timestamp columns too.
[~julianhyde], concerning the comment about monotonicity. Is it determined by
monotonicity or determinism? If we have certain grouping columns in the
materialization and a deterministic function applied on them in the grouping
column of a query, is there any cases for which we cannot roll up?
Or maybe you meant generalizing the relationship between having FLOOR in the
materialized view and having FLOOR in the query, and try to make it applicable
to any function for the rollup? That would probably require a new JIRA.
> General improvements for materialized view rewriting rule
> -
>
> Key: CALCITE-2179
> URL: https://issues.apache.org/jira/browse/CALCITE-2179
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
>Priority: Major
> Fix For: 1.16.0
>
>
> This issue is for extending {{AbstractMaterializedViewRule}} rule:
> - Support for rolling up date nodes. For instance, rewrite in the following
> case:
> {code}
> Materialization:
> select "empid", floor(cast('1997-01-20' as timestamp) to month), count(*) + 1
> as c, sum("empid") as s
> from "emps" group by "empid", floor(cast('1997-01-20' as timestamp) to month);
> Query:
> select floor(cast('1997-01-20' as timestamp) to year), sum("empid") as s
> from "emps" group by floor(cast('1997-01-20' as timestamp) to year);
> {code}
> - Add flag to enable/disable fast bail out for joins. By default it is true,
> and thus, we were only creating the rewriting in the minimal subtree of plan
> operators. For instance:
> {code}
> View: (A JOIN B) JOIN C
> Query: (((A JOIN B) JOIN D) JOIN C) JOIN E
> {code}
> We produce it at:
> {code}
> ((A JOIN B) JOIN D) JOIN C
> {code}
> But not at:
> {code}
> (((A JOIN B) JOIN D) JOIN C) JOIN E
> {code}
> This is important when the rule is used with the Volcano planner together
> with other rules, e.g. join reordering, as it prevents that the search space
> grows unnecessarily. However, if we use the rewriting rule in isolation, fast
> bail out can lead to missing rewriting opportunities (e.g. for bushy join
> trees).
> - Possibility to provide a HepProgram to optimize query branch in union
> rewritings. Note that when we produce a partial rewriting with a Union, the
> branch that will execute the (partial) query can be fully rewritten so we can
> add the compensation predicate. (We cannot do the same for views because the
> expression might not be computable if the needed subexpressions are not
> available in the view output). If we use Volcano with a determined set of
> rules, this might not be needed, hence providing this program is optional.
> - Multiple small fixes discovered while testing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2157) ClickHouse dialect implementation
[ https://issues.apache.org/jira/browse/CALCITE-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16368179#comment-16368179 ] Chris Baynes commented on CALCITE-2157: --- I've had a look at getting this into the test dataset, but since the CH dialect is not supported by Mondrian it's going to need more work. Instead I'd be happy to just add tests in JdbcAdapterTest for now and run them against a local instance. > ClickHouse dialect implementation > - > > Key: CALCITE-2157 > URL: https://issues.apache.org/jira/browse/CALCITE-2157 > Project: Calcite > Issue Type: New Feature > Components: jdbc-adapter >Reporter: Chris Baynes >Assignee: Julian Hyde >Priority: Major > > ClickHouse is a really fast columnar DBMS for OLAP: > [https://clickhouse.yandex/.|https://clickhouse.yandex/] > It has a jdbc adapter and uses mostly standard sql, though there are > differences (e.g. join syntax, datatypes, function name case-sensitivity). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2186) Implement ScalaTypeFactory
Srdan Srepfler created CALCITE-2186: --- Summary: Implement ScalaTypeFactory Key: CALCITE-2186 URL: https://issues.apache.org/jira/browse/CALCITE-2186 Project: Calcite Issue Type: New Feature Reporter: Srdan Srepfler Assignee: Julian Hyde It would be useful to have a ScalaTypeFactory which would work out of the box for case class parameters list. Possibly it could be extensible to support via extensions with some common Scala record patterns like HList's, tuples and similar. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
