[jira] [Commented] (CALCITE-2815) GeodeSchemaFactory change to pass in clientCache using geode jndi context
[ https://issues.apache.org/jira/browse/CALCITE-2815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16758008#comment-16758008 ] Sandeep Chada commented on CALCITE-2815: PR Link is https://github.com/apache/calcite/pull/1022 > GeodeSchemaFactory change to pass in clientCache using geode jndi context > - > > Key: CALCITE-2815 > URL: https://issues.apache.org/jira/browse/CALCITE-2815 > Project: Calcite > Issue Type: Improvement > Components: geode >Reporter: Sandeep Chada >Assignee: Julian Hyde >Priority: Major > > We need ability to pass clientCache to GeodeSchemaFactory create static > function. In our application we already have clientCache pre created. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2815) GeodeSchemaFactory change to pass in clientCache using geode jndi context
[ https://issues.apache.org/jira/browse/CALCITE-2815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandeep Chada updated CALCITE-2815: --- Description: We need ability to pass clientCache to GeodeSchemaFactory create static function. In our application we already have clientCache pre created. (was: We need ability to pass clientCache and regionMap to GeodeSchemaFactory create static function. In our application we already have clientCache pre created. We will also need to pass the regionMap) > GeodeSchemaFactory change to pass in clientCache using geode jndi context > - > > Key: CALCITE-2815 > URL: https://issues.apache.org/jira/browse/CALCITE-2815 > Project: Calcite > Issue Type: Improvement > Components: geode >Reporter: Sandeep Chada >Assignee: Julian Hyde >Priority: Major > > We need ability to pass clientCache to GeodeSchemaFactory create static > function. In our application we already have clientCache pre created. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2815) GeodeSchemaFactory change to pass in clientCache using geode jndi context
[ https://issues.apache.org/jira/browse/CALCITE-2815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandeep Chada updated CALCITE-2815: --- Summary: GeodeSchemaFactory change to pass in clientCache using geode jndi context (was: GeodeSchemaFactory change to pass in clienctCache and regionMap using geode jndi context) > GeodeSchemaFactory change to pass in clientCache using geode jndi context > - > > Key: CALCITE-2815 > URL: https://issues.apache.org/jira/browse/CALCITE-2815 > Project: Calcite > Issue Type: Improvement > Components: geode >Reporter: Sandeep Chada >Assignee: Julian Hyde >Priority: Major > > We need ability to pass clientCache and regionMap to GeodeSchemaFactory > create static function. In our application we already have clientCache pre > created. We will also need to pass the regionMap -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CALCITE-2770) Add bitwise aggregate functions BIT_AND, BIT_OR
[ https://issues.apache.org/jira/browse/CALCITE-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior resolved CALCITE-2770. --- Resolution: Fixed Assignee: Michael Mior (was: Julian Hyde) Fixed in. [4814943|https://github.com/apache/calcite/commit/4814943895d609813878763faf0d38adb624eac4]. > Add bitwise aggregate functions BIT_AND, BIT_OR > --- > > Key: CALCITE-2770 > URL: https://issues.apache.org/jira/browse/CALCITE-2770 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Haisheng Yuan >Assignee: Michael Mior >Priority: Major > > Almost all major database vendors provide bitwise aggregate functions such as > BIT_AND, BIT_OR. It would be nice if Calcite has these as built-in aggregate > functions. > > [1]. > [https://docs.aws.amazon.com/redshift/latest/dg/c_bitwise_aggregate_functions.html] > [2]. [https://www.postgresql.org/docs/9.1/functions-aggregate.html] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2750) PI operator incorrectly identified as dynamic function
[ https://issues.apache.org/jira/browse/CALCITE-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juhwan Kim updated CALCITE-2750: Labels: pull-request-available (was: ) > PI operator incorrectly identified as dynamic function > -- > > Key: CALCITE-2750 > URL: https://issues.apache.org/jira/browse/CALCITE-2750 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.18.0 >Reporter: Jacques Nadeau >Assignee: Juhwan Kim >Priority: Major > Labels: pull-request-available > > As part of another task I noticed that we are saying that PI is a dynamic > function. It shouldn't be. Offending code is here: > https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/fun/SqlStdOperatorTable.java#L1660 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2798) Optimizer should remove ORDER BY in sub-query, provided it has no LIMIT or OFFSET
[
https://issues.apache.org/jira/browse/CALCITE-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757761#comment-16757761
]
Haisheng Yuan commented on CALCITE-2798:
Agree with [~julianhyde]. This is exactly how
[Orca|https://github.com/greenplum-db/gporca/] query optimizer does. In Orca,
all the logical operators don't have any physical properties, e.g. order,
distribution, only physical operators have. Orca doesn't even have LogicalSort
operator, only PhysicalSort operator. The collation is only enforced on relnode
tree during property enforcement stage.
> Optimizer should remove ORDER BY in sub-query, provided it has no LIMIT or
> OFFSET
> -
>
> Key: CALCITE-2798
> URL: https://issues.apache.org/jira/browse/CALCITE-2798
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.18.0
>Reporter: Vladimir Sitnikov
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.19.0
>
>
> The following SQL performs sort twice, however inner sort can be eliminated
> {code}select * from (
> select * from "emps"
> order by "emps"."deptno"
> ) order by 1 desc{code}
> The same goes for (window calculation will sort on its own)
> {code}select row_number() over (order by "emps"."deptno") from (
> select * from "emps"
> order by "emps"."deptno" desc
> ){code}
> The same goes for SetOp (union, minus):
> {code}select * from (
> select * from "emps"
> order by "emps"."deptno"
> ) union select * from (
> select * from "emps"
> order by "emps"."deptno" desc
> ){code}
> There might be other cases like that (e.g. Aggregate, Join, Exchange,
> SortExchange)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2796) JDBC adapter should convert "GROUP BY ROLLUP(x, y)" to "GROUP BY x, y WITH ROLLUP" for MySQL 5
[
https://issues.apache.org/jira/browse/CALCITE-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757758#comment-16757758
]
Steven Talbot commented on CALCITE-2796:
Fix looks good to me.
> JDBC adapter should convert "GROUP BY ROLLUP(x, y)" to "GROUP BY x, y WITH
> ROLLUP" for MySQL 5
> --
>
> Key: CALCITE-2796
> URL: https://issues.apache.org/jira/browse/CALCITE-2796
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.18.0
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.19.0
>
>
> The JDBC adapter currently pushes down ROLLUP to all dialects. MySQL supports
> the ROLLUP and CUBE functions but only in version 8 and later. MySQL 5 has a
> similar but less powerful feature "GROUP BY ... WITH ROLLUP", but the JDBC
> adapter should use it if possible. For example,
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY ROLLUP(x, y){code}
> should be pushed down to MySQL 5 as
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY x, y WITH ROLLUP{code}
> "GROUP BY ... WITH ROLLUP" cannot be combined with "ORDER BY", but
> nevertheless guarantees output order, and therefore the JDBC adpater should
> just remove an ORDER BY clause if it is satisfied. For example,
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY ROLLUP(x, y)
> ORDER BY x, y{code}
> should be pushed down to MySQL 5 as
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY x, y WITH ROLLUP{code}
> Note that MySQL 5 supports explicit {{ASC}} and {{DESC}} keywords in {{GROUP
> BY}} to control sort direction (e.g. {{GROUP BY x DESC, y ASC WITH ROLLUP}})
> but I cannot see a reason to use it, because if there is no {{ROLLUP}}
> function we can continue to use {{ORDER BY}}. should convert "{{GROUP BY
> ROLLUP(x, y)}}" to "{{GROUP BY x, y WITH ROLLUP}}" for MySQL 5.
> MySQL 5 does not support CUBE, but note that ROLLUP with one argument is
> equivalent to CUBE with one argument; therefore we should convert "{{GROUP BY
> CUBE\(x)}}" to "{{GROUP BY x WITH ROLLUP}}".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CALCITE-2798) Optimizer should remove ORDER BY in sub-query, provided it has no LIMIT or OFFSET
[
https://issues.apache.org/jira/browse/CALCITE-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-2798.
--
Resolution: Fixed
Fix Version/s: 1.19.0
Fixed in
[cf363b5989d35bd8b4d5f14c7a99acea6e9f0f5a|https://gitbox.apache.org/repos/asf?p=calcite.git;a=commit;h=cf363b5989d35bd8b4d5f14c7a99acea6e9f0f5a].
Thanks for the PR, [~hyuan]!
> Optimizer should remove ORDER BY in sub-query, provided it has no LIMIT or
> OFFSET
> -
>
> Key: CALCITE-2798
> URL: https://issues.apache.org/jira/browse/CALCITE-2798
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.18.0
>Reporter: Vladimir Sitnikov
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.19.0
>
>
> The following SQL performs sort twice, however inner sort can be eliminated
> {code}select * from (
> select * from "emps"
> order by "emps"."deptno"
> ) order by 1 desc{code}
> The same goes for (window calculation will sort on its own)
> {code}select row_number() over (order by "emps"."deptno") from (
> select * from "emps"
> order by "emps"."deptno" desc
> ){code}
> The same goes for SetOp (union, minus):
> {code}select * from (
> select * from "emps"
> order by "emps"."deptno"
> ) union select * from (
> select * from "emps"
> order by "emps"."deptno" desc
> ){code}
> There might be other cases like that (e.g. Aggregate, Join, Exchange,
> SortExchange)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2798) Optimizer should remove ORDER BY in sub-query, provided it has no LIMIT or OFFSET
[
https://issues.apache.org/jira/browse/CALCITE-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757753#comment-16757753
]
Julian Hyde commented on CALCITE-2798:
--
Responding to your earlier comment. Probably the only collation needed is the
one at the root of the tree, and sorts elsewhere only if they are accompanied
by fetch/offset. All logical operators will produce the same result regardless
of the order of their input.
> Optimizer should remove ORDER BY in sub-query, provided it has no LIMIT or
> OFFSET
> -
>
> Key: CALCITE-2798
> URL: https://issues.apache.org/jira/browse/CALCITE-2798
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.18.0
>Reporter: Vladimir Sitnikov
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.19.0
>
>
> The following SQL performs sort twice, however inner sort can be eliminated
> {code}select * from (
> select * from "emps"
> order by "emps"."deptno"
> ) order by 1 desc{code}
> The same goes for (window calculation will sort on its own)
> {code}select row_number() over (order by "emps"."deptno") from (
> select * from "emps"
> order by "emps"."deptno" desc
> ){code}
> The same goes for SetOp (union, minus):
> {code}select * from (
> select * from "emps"
> order by "emps"."deptno"
> ) union select * from (
> select * from "emps"
> order by "emps"."deptno" desc
> ){code}
> There might be other cases like that (e.g. Aggregate, Join, Exchange,
> SortExchange)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2770) Add bitwise aggregate functions BIT_AND, BIT_OR
[ https://issues.apache.org/jira/browse/CALCITE-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757747#comment-16757747 ] Julian Hyde commented on CALCITE-2770: -- In my opinion, there is sufficient consensus among vendors (e.g. there are no implementations of them inconsistent with other vendors) that we can keep them in the "standard" table. > Add bitwise aggregate functions BIT_AND, BIT_OR > --- > > Key: CALCITE-2770 > URL: https://issues.apache.org/jira/browse/CALCITE-2770 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Haisheng Yuan >Assignee: Julian Hyde >Priority: Major > > Almost all major database vendors provide bitwise aggregate functions such as > BIT_AND, BIT_OR. It would be nice if Calcite has these as built-in aggregate > functions. > > [1]. > [https://docs.aws.amazon.com/redshift/latest/dg/c_bitwise_aggregate_functions.html] > [2]. [https://www.postgresql.org/docs/9.1/functions-aggregate.html] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2770) Add bitwise aggregate functions BIT_AND, BIT_OR
[ https://issues.apache.org/jira/browse/CALCITE-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757744#comment-16757744 ] Haisheng Yuan commented on CALCITE-2770: Well, BIT_AND, BIT_OR are not SQL standard aggregate functions (although many databases do implement these functions), should I move them to vender specific operator table? > Add bitwise aggregate functions BIT_AND, BIT_OR > --- > > Key: CALCITE-2770 > URL: https://issues.apache.org/jira/browse/CALCITE-2770 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Haisheng Yuan >Assignee: Julian Hyde >Priority: Major > > Almost all major database vendors provide bitwise aggregate functions such as > BIT_AND, BIT_OR. It would be nice if Calcite has these as built-in aggregate > functions. > > [1]. > [https://docs.aws.amazon.com/redshift/latest/dg/c_bitwise_aggregate_functions.html] > [2]. [https://www.postgresql.org/docs/9.1/functions-aggregate.html] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2796) JDBC adapter should convert "GROUP BY ROLLUP(x, y)" to "GROUP BY x, y WITH ROLLUP" for MySQL 5
[
https://issues.apache.org/jira/browse/CALCITE-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757667#comment-16757667
]
Julian Hyde commented on CALCITE-2796:
--
[~swtalbot], Can you please review?
> JDBC adapter should convert "GROUP BY ROLLUP(x, y)" to "GROUP BY x, y WITH
> ROLLUP" for MySQL 5
> --
>
> Key: CALCITE-2796
> URL: https://issues.apache.org/jira/browse/CALCITE-2796
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.18.0
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.19.0
>
>
> The JDBC adapter currently pushes down ROLLUP to all dialects. MySQL supports
> the ROLLUP and CUBE functions but only in version 8 and later. MySQL 5 has a
> similar but less powerful feature "GROUP BY ... WITH ROLLUP", but the JDBC
> adapter should use it if possible. For example,
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY ROLLUP(x, y){code}
> should be pushed down to MySQL 5 as
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY x, y WITH ROLLUP{code}
> "GROUP BY ... WITH ROLLUP" cannot be combined with "ORDER BY", but
> nevertheless guarantees output order, and therefore the JDBC adpater should
> just remove an ORDER BY clause if it is satisfied. For example,
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY ROLLUP(x, y)
> ORDER BY x, y{code}
> should be pushed down to MySQL 5 as
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY x, y WITH ROLLUP{code}
> Note that MySQL 5 supports explicit {{ASC}} and {{DESC}} keywords in {{GROUP
> BY}} to control sort direction (e.g. {{GROUP BY x DESC, y ASC WITH ROLLUP}})
> but I cannot see a reason to use it, because if there is no {{ROLLUP}}
> function we can continue to use {{ORDER BY}}. should convert "{{GROUP BY
> ROLLUP(x, y)}}" to "{{GROUP BY x, y WITH ROLLUP}}" for MySQL 5.
> MySQL 5 does not support CUBE, but note that ROLLUP with one argument is
> equivalent to CUBE with one argument; therefore we should convert "{{GROUP BY
> CUBE\(x)}}" to "{{GROUP BY x WITH ROLLUP}}".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2796) JDBC adapter should convert "GROUP BY ROLLUP(x, y)" to "GROUP BY x, y WITH ROLLUP" for MySQL 5
[
https://issues.apache.org/jira/browse/CALCITE-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-2796:
-
Affects Version/s: 1.18.0
> JDBC adapter should convert "GROUP BY ROLLUP(x, y)" to "GROUP BY x, y WITH
> ROLLUP" for MySQL 5
> --
>
> Key: CALCITE-2796
> URL: https://issues.apache.org/jira/browse/CALCITE-2796
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.18.0
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> The JDBC adapter currently pushes down ROLLUP to all dialects. MySQL supports
> the ROLLUP and CUBE functions but only in version 8 and later. MySQL 5 has a
> similar but less powerful feature "GROUP BY ... WITH ROLLUP", but the JDBC
> adapter should use it if possible. For example,
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY ROLLUP(x, y){code}
> should be pushed down to MySQL 5 as
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY x, y WITH ROLLUP{code}
> "GROUP BY ... WITH ROLLUP" cannot be combined with "ORDER BY", but
> nevertheless guarantees output order, and therefore the JDBC adpater should
> just remove an ORDER BY clause if it is satisfied. For example,
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY ROLLUP(x, y)
> ORDER BY x, y{code}
> should be pushed down to MySQL 5 as
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY x, y WITH ROLLUP{code}
> Note that MySQL 5 supports explicit {{ASC}} and {{DESC}} keywords in {{GROUP
> BY}} to control sort direction (e.g. {{GROUP BY x DESC, y ASC WITH ROLLUP}})
> but I cannot see a reason to use it, because if there is no {{ROLLUP}}
> function we can continue to use {{ORDER BY}}. should convert "{{GROUP BY
> ROLLUP(x, y)}}" to "{{GROUP BY x, y WITH ROLLUP}}" for MySQL 5.
> MySQL 5 does not support CUBE, but note that ROLLUP with one argument is
> equivalent to CUBE with one argument; therefore we should convert "{{GROUP BY
> CUBE\(x)}}" to "{{GROUP BY x WITH ROLLUP}}".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2796) JDBC adapter should convert "GROUP BY ROLLUP(x, y)" to "GROUP BY x, y WITH ROLLUP" for MySQL 5
[
https://issues.apache.org/jira/browse/CALCITE-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-2796:
-
Fix Version/s: 1.19.0
> JDBC adapter should convert "GROUP BY ROLLUP(x, y)" to "GROUP BY x, y WITH
> ROLLUP" for MySQL 5
> --
>
> Key: CALCITE-2796
> URL: https://issues.apache.org/jira/browse/CALCITE-2796
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.18.0
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.19.0
>
>
> The JDBC adapter currently pushes down ROLLUP to all dialects. MySQL supports
> the ROLLUP and CUBE functions but only in version 8 and later. MySQL 5 has a
> similar but less powerful feature "GROUP BY ... WITH ROLLUP", but the JDBC
> adapter should use it if possible. For example,
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY ROLLUP(x, y){code}
> should be pushed down to MySQL 5 as
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY x, y WITH ROLLUP{code}
> "GROUP BY ... WITH ROLLUP" cannot be combined with "ORDER BY", but
> nevertheless guarantees output order, and therefore the JDBC adpater should
> just remove an ORDER BY clause if it is satisfied. For example,
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY ROLLUP(x, y)
> ORDER BY x, y{code}
> should be pushed down to MySQL 5 as
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY x, y WITH ROLLUP{code}
> Note that MySQL 5 supports explicit {{ASC}} and {{DESC}} keywords in {{GROUP
> BY}} to control sort direction (e.g. {{GROUP BY x DESC, y ASC WITH ROLLUP}})
> but I cannot see a reason to use it, because if there is no {{ROLLUP}}
> function we can continue to use {{ORDER BY}}. should convert "{{GROUP BY
> ROLLUP(x, y)}}" to "{{GROUP BY x, y WITH ROLLUP}}" for MySQL 5.
> MySQL 5 does not support CUBE, but note that ROLLUP with one argument is
> equivalent to CUBE with one argument; therefore we should convert "{{GROUP BY
> CUBE\(x)}}" to "{{GROUP BY x WITH ROLLUP}}".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2796) JDBC adapter should convert "GROUP BY ROLLUP(x, y)" to "GROUP BY x, y WITH ROLLUP" for MySQL 5
[
https://issues.apache.org/jira/browse/CALCITE-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-2796:
-
Component/s: jdbc-adapter
> JDBC adapter should convert "GROUP BY ROLLUP(x, y)" to "GROUP BY x, y WITH
> ROLLUP" for MySQL 5
> --
>
> Key: CALCITE-2796
> URL: https://issues.apache.org/jira/browse/CALCITE-2796
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> The JDBC adapter currently pushes down ROLLUP to all dialects. MySQL supports
> the ROLLUP and CUBE functions but only in version 8 and later. MySQL 5 has a
> similar but less powerful feature "GROUP BY ... WITH ROLLUP", but the JDBC
> adapter should use it if possible. For example,
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY ROLLUP(x, y){code}
> should be pushed down to MySQL 5 as
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY x, y WITH ROLLUP{code}
> "GROUP BY ... WITH ROLLUP" cannot be combined with "ORDER BY", but
> nevertheless guarantees output order, and therefore the JDBC adpater should
> just remove an ORDER BY clause if it is satisfied. For example,
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY ROLLUP(x, y)
> ORDER BY x, y{code}
> should be pushed down to MySQL 5 as
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY x, y WITH ROLLUP{code}
> Note that MySQL 5 supports explicit {{ASC}} and {{DESC}} keywords in {{GROUP
> BY}} to control sort direction (e.g. {{GROUP BY x DESC, y ASC WITH ROLLUP}})
> but I cannot see a reason to use it, because if there is no {{ROLLUP}}
> function we can continue to use {{ORDER BY}}. should convert "{{GROUP BY
> ROLLUP(x, y)}}" to "{{GROUP BY x, y WITH ROLLUP}}" for MySQL 5.
> MySQL 5 does not support CUBE, but note that ROLLUP with one argument is
> equivalent to CUBE with one argument; therefore we should convert "{{GROUP BY
> CUBE\(x)}}" to "{{GROUP BY x WITH ROLLUP}}".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2796) JDBC adapter should convert "GROUP BY ROLLUP(x, y)" to "GROUP BY x, y WITH ROLLUP" for MySQL 5
[
https://issues.apache.org/jira/browse/CALCITE-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-2796:
-
Labels: pull-request-available (was: )
> JDBC adapter should convert "GROUP BY ROLLUP(x, y)" to "GROUP BY x, y WITH
> ROLLUP" for MySQL 5
> --
>
> Key: CALCITE-2796
> URL: https://issues.apache.org/jira/browse/CALCITE-2796
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.18.0
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.19.0
>
>
> The JDBC adapter currently pushes down ROLLUP to all dialects. MySQL supports
> the ROLLUP and CUBE functions but only in version 8 and later. MySQL 5 has a
> similar but less powerful feature "GROUP BY ... WITH ROLLUP", but the JDBC
> adapter should use it if possible. For example,
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY ROLLUP(x, y){code}
> should be pushed down to MySQL 5 as
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY x, y WITH ROLLUP{code}
> "GROUP BY ... WITH ROLLUP" cannot be combined with "ORDER BY", but
> nevertheless guarantees output order, and therefore the JDBC adpater should
> just remove an ORDER BY clause if it is satisfied. For example,
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY ROLLUP(x, y)
> ORDER BY x, y{code}
> should be pushed down to MySQL 5 as
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY x, y WITH ROLLUP{code}
> Note that MySQL 5 supports explicit {{ASC}} and {{DESC}} keywords in {{GROUP
> BY}} to control sort direction (e.g. {{GROUP BY x DESC, y ASC WITH ROLLUP}})
> but I cannot see a reason to use it, because if there is no {{ROLLUP}}
> function we can continue to use {{ORDER BY}}. should convert "{{GROUP BY
> ROLLUP(x, y)}}" to "{{GROUP BY x, y WITH ROLLUP}}" for MySQL 5.
> MySQL 5 does not support CUBE, but note that ROLLUP with one argument is
> equivalent to CUBE with one argument; therefore we should convert "{{GROUP BY
> CUBE\(x)}}" to "{{GROUP BY x WITH ROLLUP}}".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2796) JDBC adapter should convert "GROUP BY ROLLUP(x, y)" to "GROUP BY x, y WITH ROLLUP" for MySQL 5
[
https://issues.apache.org/jira/browse/CALCITE-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757644#comment-16757644
]
Julian Hyde commented on CALCITE-2796:
--
I have a proposed fix in
[https://github.com/julianhyde/calcite/tree/2796-mysql-with-rollup.] Can
someone please review?
> JDBC adapter should convert "GROUP BY ROLLUP(x, y)" to "GROUP BY x, y WITH
> ROLLUP" for MySQL 5
> --
>
> Key: CALCITE-2796
> URL: https://issues.apache.org/jira/browse/CALCITE-2796
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> The JDBC adapter currently pushes down ROLLUP to all dialects. MySQL supports
> the ROLLUP and CUBE functions but only in version 8 and later. MySQL 5 has a
> similar but less powerful feature "GROUP BY ... WITH ROLLUP", but the JDBC
> adapter should use it if possible. For example,
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY ROLLUP(x, y){code}
> should be pushed down to MySQL 5 as
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY x, y WITH ROLLUP{code}
> "GROUP BY ... WITH ROLLUP" cannot be combined with "ORDER BY", but
> nevertheless guarantees output order, and therefore the JDBC adpater should
> just remove an ORDER BY clause if it is satisfied. For example,
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY ROLLUP(x, y)
> ORDER BY x, y{code}
> should be pushed down to MySQL 5 as
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY x, y WITH ROLLUP{code}
> Note that MySQL 5 supports explicit {{ASC}} and {{DESC}} keywords in {{GROUP
> BY}} to control sort direction (e.g. {{GROUP BY x DESC, y ASC WITH ROLLUP}})
> but I cannot see a reason to use it, because if there is no {{ROLLUP}}
> function we can continue to use {{ORDER BY}}. should convert "{{GROUP BY
> ROLLUP(x, y)}}" to "{{GROUP BY x, y WITH ROLLUP}}" for MySQL 5.
> MySQL 5 does not support CUBE, but note that ROLLUP with one argument is
> equivalent to CUBE with one argument; therefore we should convert "{{GROUP BY
> CUBE\(x)}}" to "{{GROUP BY x WITH ROLLUP}}".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2329) Enhance SubQueryRemoveRule to rewrite IN operator with the constant from the left side more optimally
[
https://issues.apache.org/jira/browse/CALCITE-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757643#comment-16757643
]
Vineet Garg commented on CALCITE-2329:
--
bq. The "more optimal plan" pushes the "deptno=2" filter further towards the
table scan, whereas the original plan has it as a join condition
That make sense. I was looking at the overall plan which should be same as
EXISTS (without aggregate) according to "Since join condition is actually a
filter condition, it will be pushed into the filter during further planning
stages and join with the true condition is left."
> Enhance SubQueryRemoveRule to rewrite IN operator with the constant from the
> left side more optimally
> -
>
> Key: CALCITE-2329
> URL: https://issues.apache.org/jira/browse/CALCITE-2329
> Project: Calcite
> Issue Type: Improvement
>Reporter: Volodymyr Vysotskyi
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> Currently, for queries like this:
> {code:sql}
> select sal from emp where 2 IN (select deptno from dept)
> {code}
> SubQueryRemoveRule rules expand query plan in such a way:
> {noformat}
> LogicalProject(SAL=[$5])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8])
> LogicalJoin(condition=[=(2, $9)], joinType=[inner])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalProject(DEPTNO=[$0])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> {noformat}
> Since join condition is actually a filter condition, it will be pushed into
> the filter during further planning stages and join with the true condition is
> left.
> But these types of the queries may be rewritten in the same way as EXISTS
> queries:
> {code:sql}
> select sal from emp where EXISTS (select deptno from dept where deptno=2)
> {code}
> with the more optimal plan:
> {noformat}
> LogicalProject(SAL=[$5])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8])
> LogicalJoin(condition=[true], joinType=[inner])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalAggregate(group=[{0}])
> LogicalProject(i=[true])
> LogicalFilter(condition=[=($0, 2)])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2796) JDBC adapter should convert "GROUP BY ROLLUP(x, y)" to "GROUP BY x, y WITH ROLLUP" for MySQL 5
[
https://issues.apache.org/jira/browse/CALCITE-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-2796:
-
Description:
The JDBC adapter currently pushes down ROLLUP to all dialects. MySQL supports
the ROLLUP and CUBE functions but only in version 8 and later. MySQL 5 has a
similar but less powerful feature "GROUP BY ... WITH ROLLUP", but the JDBC
adapter should use it if possible. For example,
{code:java}
SELECT x, y
FROM t
GROUP BY ROLLUP(x, y){code}
should be pushed down to MySQL 5 as
{code:java}
SELECT x, y
FROM t
GROUP BY x, y WITH ROLLUP{code}
"GROUP BY ... WITH ROLLUP" cannot be combined with "ORDER BY", but nevertheless
guarantees output order, and therefore the JDBC adpater should just remove an
ORDER BY clause if it is satisfied. For example,
{code:java}
SELECT x, y
FROM t
GROUP BY ROLLUP(x, y)
ORDER BY x, y{code}
should be pushed down to MySQL 5 as
{code:java}
SELECT x, y
FROM t
GROUP BY x, y WITH ROLLUP{code}
Note that MySQL 5 supports explicit {{ASC}} and {{DESC}} keywords in {{GROUP
BY}} to control sort direction (e.g. {{GROUP BY x DESC, y ASC WITH ROLLUP}})
but I cannot see a reason to use it, because if there is no {{ROLLUP}} function
we can continue to use {{ORDER BY}}. should convert "{{GROUP BY ROLLUP(x, y)}}"
to "{{GROUP BY x, y WITH ROLLUP}}" for MySQL 5.
MySQL 5 does not support CUBE, but note that ROLLUP with one argument is
equivalent to CUBE with one argument; therefore we should convert "{{GROUP BY
CUBE\(x)}}" to "{{GROUP BY x WITH ROLLUP}}".
was:
The JDBC adapter currently pushes down ROLLUP to all dialects. MySQL supports
the ROLLUP and CUBE functions but only in version 8 and later. MySQL 5 has a
similar but less powerful feature "GROUP BY ... WITH ROLLUP", but the JDBC
adapter should use it if possible. For example,
{code:java}
SELECT x, y
FROM t
GROUP BY ROLLUP(x, y){code}
should be pushed down to MySQL 5 as
{code:java}
SELECT x, y
FROM t
GROUP BY x, y WITH ROLLUP{code}
"GROUP BY ... WITH ROLLUP" cannot be combined with "ORDER BY", but nevertheless
guarantees output order, and therefore the JDBC adpater should just remove an
ORDER BY clause if it is satisfied. For example,
{code:java}
SELECT x, y
FROM t
GROUP BY ROLLUP(x, y)
ORDER BY x, y{code}
should be pushed down to MySQL 5 as
{code:java}
SELECT x, y
FROM t
GROUP BY x, y WITH ROLLUP{code}
Note that MySQL 5 supports explicit {{ASC}} and {{DESC}} keywords in {{GROUP
BY}} to control sort direction (e.g. {{GROUP BY x DESC, y ASC WITH ROLLUP}})
but I cannot see a reason to use it, because if there is no {{ROLLUP}} function
we can continue to use {{ORDER BY}}. should convert "{{GROUP BY ROLLUP(x, y)}}"
to "{{GROUP BY x, y WITH ROLLUP}}" for MySQL 5.
MySQL 5 does not support CUBE, but note that ROLLUP with one argument is
equivalent to CUBE with one argument; therefore we should convert "{{GROUP BY
CUBE(x)}}" to "{{GROUP BY x WITH ROLLUP}}".
> JDBC adapter should convert "GROUP BY ROLLUP(x, y)" to "GROUP BY x, y WITH
> ROLLUP" for MySQL 5
> --
>
> Key: CALCITE-2796
> URL: https://issues.apache.org/jira/browse/CALCITE-2796
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> The JDBC adapter currently pushes down ROLLUP to all dialects. MySQL supports
> the ROLLUP and CUBE functions but only in version 8 and later. MySQL 5 has a
> similar but less powerful feature "GROUP BY ... WITH ROLLUP", but the JDBC
> adapter should use it if possible. For example,
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY ROLLUP(x, y){code}
> should be pushed down to MySQL 5 as
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY x, y WITH ROLLUP{code}
> "GROUP BY ... WITH ROLLUP" cannot be combined with "ORDER BY", but
> nevertheless guarantees output order, and therefore the JDBC adpater should
> just remove an ORDER BY clause if it is satisfied. For example,
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY ROLLUP(x, y)
> ORDER BY x, y{code}
> should be pushed down to MySQL 5 as
> {code:java}
> SELECT x, y
> FROM t
> GROUP BY x, y WITH ROLLUP{code}
> Note that MySQL 5 supports explicit {{ASC}} and {{DESC}} keywords in {{GROUP
> BY}} to control sort direction (e.g. {{GROUP BY x DESC, y ASC WITH ROLLUP}})
> but I cannot see a reason to use it, because if there is no {{ROLLUP}}
> function we can continue to use {{ORDER BY}}. should convert "{{GROUP BY
> ROLLUP(x, y)}}" to "{{GROUP BY x, y WITH ROLLUP}}" for MySQL 5.
> MySQL 5 does not support CUBE, but note that ROLLUP with one argument is
> equivalent to CUBE with one argument; therefore we should convert "{{GROUP BY
> CUBE\(x)}}" to "{{GROUP BY x WITH ROLLUP}}".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2791) Add the JSON_TYPE function
[ https://issues.apache.org/jira/browse/CALCITE-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hongze Zhang updated CALCITE-2791: -- Attachment: (was: xuqianjin.url) > Add the JSON_TYPE function > -- > > Key: CALCITE-2791 > URL: https://issues.apache.org/jira/browse/CALCITE-2791 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: xuqianjin >Assignee: Julian Hyde >Priority: Major > Labels: https://github.com/apache/calcite/pull/1013 > > The data in json can be =, <, <=, >, >=, <>,! =, and <=>. But the data types > in json can be diverse, so when you compare different types, you have a > priority, and the high priority is greater than the low priority (you can > view the types with the JSON_TYPE() function). The priorities are as follows: > BOOLEAN > ARRAY > OBJECT > STRING > INTEGER > DOUBLE > NULL -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2791) Add the JSON_TYPE function
[ https://issues.apache.org/jira/browse/CALCITE-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hongze Zhang updated CALCITE-2791: -- Attachment: xuqianjin.url > Add the JSON_TYPE function > -- > > Key: CALCITE-2791 > URL: https://issues.apache.org/jira/browse/CALCITE-2791 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: xuqianjin >Assignee: Julian Hyde >Priority: Major > Labels: https://github.com/apache/calcite/pull/1013 > Attachments: xuqianjin.url > > > The data in json can be =, <, <=, >, >=, <>,! =, and <=>. But the data types > in json can be diverse, so when you compare different types, you have a > priority, and the high priority is greater than the low priority (you can > view the types with the JSON_TYPE() function). The priorities are as follows: > BOOLEAN > ARRAY > OBJECT > STRING > INTEGER > DOUBLE > NULL -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2757) DISTINCT not being handled correctly in RelToSqlConverter
[ https://issues.apache.org/jira/browse/CALCITE-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757250#comment-16757250 ] KrishnaKant Agrawal commented on CALCITE-2757: -- Hi, Can somebody please look into this and guide me if possible? > DISTINCT not being handled correctly in RelToSqlConverter > - > > Key: CALCITE-2757 > URL: https://issues.apache.org/jira/browse/CALCITE-2757 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: KrishnaKant Agrawal >Assignee: Julian Hyde >Priority: Major > Labels: pull-request-available > > SELECT DISTINCT sum( x ) OVER (PARTITION BY y) FROM t > is valid (per SQL standard) but > SELECT sum( x ) OVER (PARTITION BY y) > FROM t > GROUP BY sum( x ) OVER (PARTITION BY y) > is not. For example, given the query > select sum(deptno) over (partition by loc) > from dept > group by sum(deptno) over (partition by loc); > Oracle gives > ORA-00934: group function is not allowed here > Therefore we should generate a sub-query, something like this: > SELECT c1 > FROM ( > SELECT sum(deptno) OVER (PARTITION BY loc) > FROM dept) AS t > GROUP BY c1; > > This will be achieved by Adding a new condition for setting the needNew Flag > in SqlImplemontor.Builder.builder() as true in case there are Aggregate > Expressions being passed as Group By Keys. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2791) Add the JSON_TYPE function
[ https://issues.apache.org/jira/browse/CALCITE-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757200#comment-16757200 ] xuqianjin edited comment on CALCITE-2791 at 1/31/19 12:57 PM: -- hi [~zhztheplayer] Some discussions about the adding of MySQL JSON functions in the dev list. I think it's a great idea. We can start talking about this. best qianjin was (Author: x1q1j1): hi [~zhztheplayer] Some discussions about the adding of MySQL JSON functions in the dev list. We can start talking about this. best qianjin > Add the JSON_TYPE function > -- > > Key: CALCITE-2791 > URL: https://issues.apache.org/jira/browse/CALCITE-2791 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: xuqianjin >Assignee: Julian Hyde >Priority: Major > Labels: https://github.com/apache/calcite/pull/1013 > > The data in json can be =, <, <=, >, >=, <>,! =, and <=>. But the data types > in json can be diverse, so when you compare different types, you have a > priority, and the high priority is greater than the low priority (you can > view the types with the JSON_TYPE() function). The priorities are as follows: > BOOLEAN > ARRAY > OBJECT > STRING > INTEGER > DOUBLE > NULL -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2791) Add the JSON_TYPE function
[ https://issues.apache.org/jira/browse/CALCITE-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757200#comment-16757200 ] xuqianjin commented on CALCITE-2791: hi [~zhztheplayer] Some discussions about the adding of MySQL JSON functions in the dev list. We can start talking about this. best qianjin > Add the JSON_TYPE function > -- > > Key: CALCITE-2791 > URL: https://issues.apache.org/jira/browse/CALCITE-2791 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: xuqianjin >Assignee: Julian Hyde >Priority: Major > Labels: https://github.com/apache/calcite/pull/1013 > > The data in json can be =, <, <=, >, >=, <>,! =, and <=>. But the data types > in json can be diverse, so when you compare different types, you have a > priority, and the high priority is greater than the low priority (you can > view the types with the JSON_TYPE() function). The priorities are as follows: > BOOLEAN > ARRAY > OBJECT > STRING > INTEGER > DOUBLE > NULL -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2791) Add the JSON_TYPE function
[ https://issues.apache.org/jira/browse/CALCITE-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757196#comment-16757196 ] xuqianjin commented on CALCITE-2791: hi [~zhztheplayer] I have modified this PR, can you take a look at it sometime? Thank you very much. best qianjin > Add the JSON_TYPE function > -- > > Key: CALCITE-2791 > URL: https://issues.apache.org/jira/browse/CALCITE-2791 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: xuqianjin >Assignee: Julian Hyde >Priority: Major > Labels: https://github.com/apache/calcite/pull/1013 > > The data in json can be =, <, <=, >, >=, <>,! =, and <=>. But the data types > in json can be diverse, so when you compare different types, you have a > priority, and the high priority is greater than the low priority (you can > view the types with the JSON_TYPE() function). The priorities are as follows: > BOOLEAN > ARRAY > OBJECT > STRING > INTEGER > DOUBLE > NULL -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2812) Add algebraic operators to allow expressing recursive queries
[
https://issues.apache.org/jira/browse/CALCITE-2812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757003#comment-16757003
]
Stamatis Zampetakis commented on CALCITE-2812:
--
Instead of "delta" I think it would be more appropriate to use the term
"transient" or "temporary" for such kind of tables. Both terms appear in the
SQL standard.
{quote}A transient table is a named table that may come into existence
implicitly during the evaluation of a or the execution of a trigger. A transient table is identified by a
if it arises during
the evaluation of a , or by a if it
arises during the execution of a
trigger. Such tables exist only for the duration of the executing SQL-statement
containing the
or for the duration of the executing trigger.
{quote}
{quote}A temporary base table is either a global temporary table, a created
local temporary table, or a declared local
temporary table
A global temporary table is a named table defined by a that
specifies GLOBAL TEMPORARY.
Global temporary tables are effectively materialized only when referenced in an
SQL-session. Every SQL-
session that references a global temporary table causes a distinct instance of
that global temporary table (i.e.,
a multiset of rows that is visible only to that SQL-session) to be
materialized. That is, the multiset of rows that
is reference by the of a global temporary table cannot be shared
between SQL-sessions.
{quote}
Since the delta table comes into existence only for the execution of the query,
maybe the "transient" term is more appropriate.
> Add algebraic operators to allow expressing recursive queries
> -
>
> Key: CALCITE-2812
> URL: https://issues.apache.org/jira/browse/CALCITE-2812
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.18.0
>Reporter: Stamatis Zampetakis
>Assignee: Julian Hyde
>Priority: Major
> Fix For: next
>
>
> In order to parse, optimize, and execute, recursive queries, expressed in
> SQL, datalog, SPARQL, or other high level language we need first to be able
> to represent recursive queries in relational algebra.
> The subject has been previously discussed in the dev list (see thread with
> title [Recursive query, graph query,
> Datalog|http://mail-archives.apache.org/mod_mbox/calcite-dev/201712.mbox/%3CCAPSgeESFyih9_hf9=uMWFN00BCR7sjf0T+FRY2=ary3ygm1...@mail.gmail.com%3E])
> where various ideas and optimizations were proposed.
> In this issue, we attempt to address only the algebraic part providing the
> following:
> # logical operator(s) for expressing recursion;
> # naive physical operator(s) for the Enumerable convention;
> # ability to create a recusive plan using the RelBuilder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
