[jira] [Updated] (CALCITE-2250) Avatica with HSQLDB backend hangs when using multiple transactions
[ https://issues.apache.org/jira/browse/CALCITE-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francis Chuang updated CALCITE-2250: Description: I have a unit test in avatica-go that executes multiple transactions against avatica to test the optimistic concurrency. I noticed that this test hangs avatica when using the HSQLDB backend. I was not able to work out how to increase the log verbosity of avatica, so there were no meaningful logs. Reproducing is simple: * Open connection 1 and create database tables. * Disable autocommit on connection 1 * Open connection 2 * Disable autocommit on connection 2 * Connection 1 executes a SELECT query * Connection 2 executes an INSERT query The last operation hangs avatica and we never get a response. I have attached a zip containing the protobuf messages being sent to avatica and a bash script to send the messages to avatica. Simply run ./hang-avatica-hsqldb.sh and it will send the messages to avatica. CURL will need to be installed and it assumes avatica is running on localhost:8765 was: I have a unit test in avatica-go that executes multiple transactions against avatica to test the optimistic concurrency. I noticed that this test hangs avatica when using the HSQLDB backend. I was not able to work out how to increase the log verbosity of avatica, so there were no meaningful logs. The operation is simple: * Open connection 1 and create database tables. * Disable autocommit on connection 1 * Open connection 2 * Disable autocommit on connection 2 * Connection 1 executes a SELECT query * Connection 2 executes an INSERT query The last operation hangs avatica and we never get a response. I have attached a zip containing the protobuf messages being sent to avatica and a bash script to send the messages to avatica. Simply run ./hang-avatica-hsqldb.sh and it will send the messages to avatica. CURL will need to be installed and it assumes avatica is running on localhost:8765 > Avatica with HSQLDB backend hangs when using multiple transactions > -- > > Key: CALCITE-2250 > URL: https://issues.apache.org/jira/browse/CALCITE-2250 > Project: Calcite > Issue Type: Bug > Components: avatica >Affects Versions: avatica-1.11.0 >Reporter: Francis Chuang >Priority: Major > Attachments: hang-avatica.zip > > > I have a unit test in avatica-go that executes multiple transactions against > avatica to test the optimistic concurrency. > I noticed that this test hangs avatica when using the HSQLDB backend. I was > not able to work out how to increase the log verbosity of avatica, so there > were no meaningful logs. > Reproducing is simple: > * Open connection 1 and create database tables. > * Disable autocommit on connection 1 > * Open connection 2 > * Disable autocommit on connection 2 > * Connection 1 executes a SELECT query > * Connection 2 executes an INSERT query > The last operation hangs avatica and we never get a response. > I have attached a zip containing the protobuf messages being sent to avatica > and a bash script to send the messages to avatica. > Simply run ./hang-avatica-hsqldb.sh and it will send the messages to avatica. > CURL will need to be installed and it assumes avatica is running on > localhost:8765 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2250) Avatica with HSQLDB backend hangs when using multiple transactions
[ https://issues.apache.org/jira/browse/CALCITE-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francis Chuang updated CALCITE-2250: Description: I have a unit test in avatica-go that executes multiple transactions against avatica to test the optimistic concurrency. I noticed that this test hangs avatica when using the HSQLDB backend. I was not able to work out how to increase the log verbosity of avatica, so there were no meaningful logs. The operation is simple: * Open connection 1 and create database tables. * Disable autocommit on connection 1 * Open connection 2 * Disable autocommit on connection 2 * Connection 1 executes a SELECT query * Connection 2 executes an INSERT query The last operation hangs avatica and we never get a response. I have attached a zip containing the protobuf messages being sent to avatica and a bash script to send the messages to avatica. Simply run ./hang-avatica-hsqldb.sh and it will send the messages to avatica. CURL will need to be installed and it assumes avatica is running on localhost:8765 was: I have a unit test in avatica-go that executes multiple transactions against avatica to test the optimistic concurrency. I noticed that this test hangs avatica when using the HSQLDB backend. I was not able to work out how to increase the log verbosity of avatica, so there was no meaningful logs. The operation is simple: * Open connection 1 and create database tables. * Disable autocommit on connection 1 * Open connection 2 * Disable autocommit on connection 2 * Connection 1 executes a SELECT query * Connection 2 executes an INSERT query The last operation hangs avatica and we never get a response. I have attached a zip containing the protobuf messages being sent to avatica and a bash script to send the messages to avatica. Simply run ./hang-avatica-hsqldb.sh and it will send the messages to avatica. CURL will need to be installed and it assumes avatica is running on localhost:8765 > Avatica with HSQLDB backend hangs when using multiple transactions > -- > > Key: CALCITE-2250 > URL: https://issues.apache.org/jira/browse/CALCITE-2250 > Project: Calcite > Issue Type: Bug > Components: avatica >Affects Versions: avatica-1.11.0 >Reporter: Francis Chuang >Priority: Major > Attachments: hang-avatica.zip > > > I have a unit test in avatica-go that executes multiple transactions against > avatica to test the optimistic concurrency. > I noticed that this test hangs avatica when using the HSQLDB backend. I was > not able to work out how to increase the log verbosity of avatica, so there > were no meaningful logs. > The operation is simple: > * Open connection 1 and create database tables. > * Disable autocommit on connection 1 > * Open connection 2 > * Disable autocommit on connection 2 > * Connection 1 executes a SELECT query > * Connection 2 executes an INSERT query > The last operation hangs avatica and we never get a response. > I have attached a zip containing the protobuf messages being sent to avatica > and a bash script to send the messages to avatica. > Simply run ./hang-avatica-hsqldb.sh and it will send the messages to avatica. > CURL will need to be installed and it assumes avatica is running on > localhost:8765 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2250) Avatica with HSQLDB backend hangs when using multiple transactions
[ https://issues.apache.org/jira/browse/CALCITE-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francis Chuang updated CALCITE-2250: Attachment: hang-avatica.zip > Avatica with HSQLDB backend hangs when using multiple transactions > -- > > Key: CALCITE-2250 > URL: https://issues.apache.org/jira/browse/CALCITE-2250 > Project: Calcite > Issue Type: Bug > Components: avatica >Affects Versions: avatica-1.11.0 >Reporter: Francis Chuang >Priority: Major > Attachments: hang-avatica.zip > > > I have a unit test in avatica-go that executes multiple transactions against > avatica to test the optimistic concurrency. > I noticed that this test hangs avatica when using the HSQLDB backend. I was > not able to work out how to increase the log verbosity of avatica, so there > was no meaningful logs. > The operation is simple: > * Open connection 1 and create database tables. > * Disable autocommit on connection 1 > * Open connection 2 > * Disable autocommit on connection 2 > * Connection 1 executes a SELECT query > * Connection 2 executes an INSERT query > The last operation hangs avatica and we never get a response. > I have attached a zip containing the protobuf messages being sent to avatica > and a bash script to send the messages to avatica. > Simply run ./hang-avatica-hsqldb.sh and it will send the messages to avatica. > CURL will need to be installed and it assumes avatica is running on > localhost:8765 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2250) Avatica with HSQLDB backend hangs when using multiple transactions
Francis Chuang created CALCITE-2250: --- Summary: Avatica with HSQLDB backend hangs when using multiple transactions Key: CALCITE-2250 URL: https://issues.apache.org/jira/browse/CALCITE-2250 Project: Calcite Issue Type: Bug Components: avatica Affects Versions: avatica-1.11.0 Reporter: Francis Chuang I have a unit test in avatica-go that executes multiple transactions against avatica to test the optimistic concurrency. I noticed that this test hangs avatica when using the HSQLDB backend. I was not able to work out how to increase the log verbosity of avatica, so there was no meaningful logs. The operation is simple: * Open connection 1 and create database tables. * Disable autocommit on connection 1 * Open connection 2 * Disable autocommit on connection 2 * Connection 1 executes a SELECT query * Connection 2 executes an INSERT query The last operation hangs avatica and we never get a response. I have attached a zip containing the protobuf messages being sent to avatica and a bash script to send the messages to avatica. Simply run ./hang-avatica-hsqldb.sh and it will send the messages to avatica. CURL will need to be installed and it assumes avatica is running on localhost:8765 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2247) Add rule to push in condition condition into a related disjunctive expression
[
https://issues.apache.org/jira/browse/CALCITE-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434548#comment-16434548
]
Zoltan Haindrich commented on CALCITE-2247:
---
When I've looked into RexImplicationChecker it looked like I will not be able
to get a rowType for it in every cases in which RexSimplify is being used.
The usage of predicates in RexSimplify seems to be a better way of doing this
than my existing approach; I think that probably the last case could also be
covered by examining the comparisions before simplifing more complex operands.
I'll take a look at it tomorrow :)
> Add rule to push in condition condition into a related disjunctive expression
> -
>
> Key: CALCITE-2247
> URL: https://issues.apache.org/jira/browse/CALCITE-2247
> Project: Calcite
> Issue Type: Improvement
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Major
>
> Simplify expressions like: {code}a = 1 AND (a = 1 OR a = 2){code} to {code}a
> = 1{code}
> Conditions to apply will be:
> * in an AND condition there exists a comparison(c) and an OR (o)
> * o and c only reference 1 variable
> See HIVE-19097 for more info.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-782) Mongo Groups missing values
[
https://issues.apache.org/jira/browse/CALCITE-782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jess Balint updated CALCITE-782:
Description:
If you do something like:
{code:sql}
select count("collection"."_id") as "m0" , "collection"."registeredYear" as
"c0", "collection"."registeredQuarter" as "c1"
from "collection" as "collection"
where "collection"."registeredYear" = 2015
group by "collection"."registeredQuarter", "collection"."registeredYear";
{code}
registeredYear isn't added to the $project: clause and so isn't returned by
mongo.
was:
If you do something like:
select count("collection"."_id") as "m0" , "collection"."registeredYear" as
"c0", "collection"."registeredQuarter" as "c1" from "collection" as
"collection" where "collection"."registeredYear" = 2015 group by
"collection"."registeredQuarter", "collection"."registeredYear";
registeredYear isn't added to the $project: clause and so isn't returned by
mongo.
> Mongo Groups missing values
> ---
>
> Key: CALCITE-782
> URL: https://issues.apache.org/jira/browse/CALCITE-782
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.4.0-incubating
>Reporter: Tom Barber
>Assignee: Julian Hyde
>Priority: Major
> Fix For: next
>
>
> If you do something like:
> {code:sql}
> select count("collection"."_id") as "m0" , "collection"."registeredYear" as
> "c0", "collection"."registeredQuarter" as "c1"
> from "collection" as "collection"
> where "collection"."registeredYear" = 2015
> group by "collection"."registeredQuarter", "collection"."registeredYear";
> {code}
> registeredYear isn't added to the $project: clause and so isn't returned by
> mongo.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2247) Add rule to push in condition condition into a related disjunctive expression
[
https://issues.apache.org/jira/browse/CALCITE-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434518#comment-16434518
]
Julian Hyde commented on CALCITE-2247:
--
I thought about this some more. RexSimplify has predicates. Suppose after
you've seen {{a = 1}} you create a new RexSimplify with {{a = 1}} as a
predicate. Then you can simplify {{a = 1 OR a = 2}} to {{a = 1}}.
This way, we would be able to deal with more complex cases, e.g. simplify {{a >
10 and (a = 5 or a = 15)}} to {{a = 15}}.
There's a slight problem with this: it's very dependent on the order of the
items in the AND. We would not be able to optimize {{(a = 5 or a = 15) and a >
10}}, for instance. But we can live with that.
Whatever algorithm you choose, you should add tests to {{RexProgramTest}}. We
need to be able to test simplifications as unit tests, not just as part of
{{RelOptRulesTest}}.
> Add rule to push in condition condition into a related disjunctive expression
> -
>
> Key: CALCITE-2247
> URL: https://issues.apache.org/jira/browse/CALCITE-2247
> Project: Calcite
> Issue Type: Improvement
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Major
>
> Simplify expressions like: {code}a = 1 AND (a = 1 OR a = 2){code} to {code}a
> = 1{code}
> Conditions to apply will be:
> * in an AND condition there exists a comparison(c) and an OR (o)
> * o and c only reference 1 variable
> See HIVE-19097 for more info.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2237) JDK 10 builds fail with NPE due to SUREFIRE-1439
[ https://issues.apache.org/jira/browse/CALCITE-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434246#comment-16434246 ] Josh Elser commented on CALCITE-2237: - Perfect. Thanks for letting me know. Will watch those too. Thanks for doing this (and thanks to Julian for giving you a review!) > JDK 10 builds fail with NPE due to SUREFIRE-1439 > > > Key: CALCITE-2237 > URL: https://issues.apache.org/jira/browse/CALCITE-2237 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.17.0 >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: 1.17.0 > > > SUREFIRE-1439 causes an NPE when using JDK 10. CALCITE-2225 upgraded to > Apache parent pom 19 which included Surefire 2.20.1. MPOM-184 is tracking the > fix for Apache parent pom 20. We should update to Surefire 2.21.0 to ensure > that builds function on JDK 10. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2237) JDK 10 builds fail with NPE due to SUREFIRE-1439
[ https://issues.apache.org/jira/browse/CALCITE-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434217#comment-16434217 ] Kevin Risden edited comment on CALCITE-2237 at 4/11/18 4:56 PM: [~elserj] - See CALCITE-2063 - There are still failures with Pig (CALCITE-2238) and Spark (CALCITE-2239) adapters due to what looks like Hadoop incompatibilities with JDK 10. I have not had a chance to look closer yet. was (Author: risdenk): [~elserj] - See CALCITE-2063 - There are still failures with Pig (CALCITE-2238) and Spark (CALICTE-2239) adapters due to what looks like Hadoop incompatibilities with JDK 10. I have not had a chance to look closer yet. > JDK 10 builds fail with NPE due to SUREFIRE-1439 > > > Key: CALCITE-2237 > URL: https://issues.apache.org/jira/browse/CALCITE-2237 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.17.0 >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: 1.17.0 > > > SUREFIRE-1439 causes an NPE when using JDK 10. CALCITE-2225 upgraded to > Apache parent pom 19 which included Surefire 2.20.1. MPOM-184 is tracking the > fix for Apache parent pom 20. We should update to Surefire 2.21.0 to ensure > that builds function on JDK 10. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2237) JDK 10 builds fail with NPE due to SUREFIRE-1439
[ https://issues.apache.org/jira/browse/CALCITE-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434217#comment-16434217 ] Kevin Risden commented on CALCITE-2237: --- [~elserj] - See CALCITE-2063 - There are still failures with Pig (CALCITE-2238) and Spark (CALICTE-2239) adapters due to what looks like Hadoop incompatibilities with JDK 10. I have not had a chance to look closer yet. > JDK 10 builds fail with NPE due to SUREFIRE-1439 > > > Key: CALCITE-2237 > URL: https://issues.apache.org/jira/browse/CALCITE-2237 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.17.0 >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: 1.17.0 > > > SUREFIRE-1439 causes an NPE when using JDK 10. CALCITE-2225 upgraded to > Apache parent pom 19 which included Surefire 2.20.1. MPOM-184 is tracking the > fix for Apache parent pom 20. We should update to Surefire 2.21.0 to ensure > that builds function on JDK 10. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2237) JDK 10 builds fail with NPE due to SUREFIRE-1439
[ https://issues.apache.org/jira/browse/CALCITE-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434207#comment-16434207 ] Josh Elser commented on CALCITE-2237: - Should I try flipping jdk10 back on for Calcite's jenkins build now, [~risdenk]? Or is there more incoming? :) > JDK 10 builds fail with NPE due to SUREFIRE-1439 > > > Key: CALCITE-2237 > URL: https://issues.apache.org/jira/browse/CALCITE-2237 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.17.0 >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: 1.17.0 > > > SUREFIRE-1439 causes an NPE when using JDK 10. CALCITE-2225 upgraded to > Apache parent pom 19 which included Surefire 2.20.1. MPOM-184 is tracking the > fix for Apache parent pom 20. We should update to Surefire 2.21.0 to ensure > that builds function on JDK 10. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2247) Add rule to push in condition condition into a related disjunctive expression
[
https://issues.apache.org/jira/browse/CALCITE-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434014#comment-16434014
]
Julian Hyde commented on CALCITE-2247:
--
RexImplicationChecker is a good idea in principle but I don't want simplify to
become an expensive code path. Use it if it doesn't add complexity to the
algorithm.
I do think the current case is too limited. If the visitor cannot easily be
extended to support say <, >= then it is technical debt.
> Add rule to push in condition condition into a related disjunctive expression
> -
>
> Key: CALCITE-2247
> URL: https://issues.apache.org/jira/browse/CALCITE-2247
> Project: Calcite
> Issue Type: Improvement
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Major
>
> Simplify expressions like: {code}a = 1 AND (a = 1 OR a = 2){code} to {code}a
> = 1{code}
> Conditions to apply will be:
> * in an AND condition there exists a comparison(c) and an OR (o)
> * o and c only reference 1 variable
> See HIVE-19097 for more info.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2247) Add rule to push in condition condition into a related disjunctive expression
[
https://issues.apache.org/jira/browse/CALCITE-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-2247:
-
Description:
Simplify expressions like: {code}a = 1 AND (a = 1 OR a = 2){code} to {code}a =
1{code}
Conditions to apply will be:
* in an AND condition there exists a comparison(c) and an OR (o)
* o and c only reference 1 variable
See HIVE-19097 for more info.
was:
simplify expressions like: {a = 1 && (a=1 || a=2)} to {a=1}
conditions to apply will be:
* in an AND condition exists a comparision(c) and an OR (o)
* o and c only reference 1 variable
HIVE-19097 for more info
> Add rule to push in condition condition into a related disjunctive expression
> -
>
> Key: CALCITE-2247
> URL: https://issues.apache.org/jira/browse/CALCITE-2247
> Project: Calcite
> Issue Type: Improvement
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Major
>
> Simplify expressions like: {code}a = 1 AND (a = 1 OR a = 2){code} to {code}a
> = 1{code}
> Conditions to apply will be:
> * in an AND condition there exists a comparison(c) and an OR (o)
> * o and c only reference 1 variable
> See HIVE-19097 for more info.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2249) AggregateJoinTransposeRule generates inequivalent nodes if Aggregate relNode contains distinct aggregate function.
[
https://issues.apache.org/jira/browse/CALCITE-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433566#comment-16433566
]
jingzhang commented on CALCITE-2249:
Cool. I submit a pr [https://github.com/apache/calcite/pull/661.] Please have a
look at it.
> AggregateJoinTransposeRule generates inequivalent nodes if Aggregate relNode
> contains distinct aggregate function.
> --
>
> Key: CALCITE-2249
> URL: https://issues.apache.org/jira/browse/CALCITE-2249
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: jingzhang
>Assignee: Julian Hyde
>Priority: Major
>
> AggregateJoinTransposeRule generates inequivalent nodes if Aggregate relNode
> contains distinct aggregate function.
> T1
> ||a (String)||b (int)||
> |A|1|
> |A|2|
> |B|2|
> |C|3|
>
> T2
> ||c(int)||
> |1|
> |1|
> |2|
> For the following sql,
> {code:java}
> select count (distinct a) from t1, t2 where t1.b = t2.c
> {code}
> Aggregate would generate following node tree, which is inequivalent with
> original node tree.
> {code:java}
> LogicalAggregate(group=[{}], EXPR$0=[$SUM0($4)])
> +- LogicalProject(b=[$0], EXPR$0=[$1], c=[$2], $f1=[$3], $f4=[*($1, $3)])
> +- LogicalJoin(condition=[=($0, $2)], joinType=[inner])
> :- LogicalAggregate(group=[\{1}], EXPR$0=[COUNT(DISTINCT $0)])
> : +- LogicalTableScan(table=[[t1]])
> +- LogicalAggregate(group=[\{0}], agg#0=[COUNT()])
> +- LogicalTableScan(table=[[t2]])
> {code}
> Based on the converted plan, result is 4; while the correct answer is 2.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2249) AggregateJoinTransposeRule generates inequivalent nodes if Aggregate relNode contains distinct aggregate function.
[
https://issues.apache.org/jira/browse/CALCITE-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433540#comment-16433540
]
Haisheng Yuan edited comment on CALCITE-2249 at 4/11/18 8:07 AM:
-
We can bail out for distinct aggregate function.
was (Author: hyuan):
We can bail out for distinct aggregation.
> AggregateJoinTransposeRule generates inequivalent nodes if Aggregate relNode
> contains distinct aggregate function.
> --
>
> Key: CALCITE-2249
> URL: https://issues.apache.org/jira/browse/CALCITE-2249
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: jingzhang
>Assignee: Julian Hyde
>Priority: Major
>
> AggregateJoinTransposeRule generates inequivalent nodes if Aggregate relNode
> contains distinct aggregate function.
> T1
> ||a (String)||b (int)||
> |A|1|
> |A|2|
> |B|2|
> |C|3|
>
> T2
> ||c(int)||
> |1|
> |1|
> |2|
> For the following sql,
> {code:java}
> select count (distinct a) from t1, t2 where t1.b = t2.c
> {code}
> Aggregate would generate following node tree, which is inequivalent with
> original node tree.
> {code:java}
> LogicalAggregate(group=[{}], EXPR$0=[$SUM0($4)])
> +- LogicalProject(b=[$0], EXPR$0=[$1], c=[$2], $f1=[$3], $f4=[*($1, $3)])
> +- LogicalJoin(condition=[=($0, $2)], joinType=[inner])
> :- LogicalAggregate(group=[\{1}], EXPR$0=[COUNT(DISTINCT $0)])
> : +- LogicalTableScan(table=[[t1]])
> +- LogicalAggregate(group=[\{0}], agg#0=[COUNT()])
> +- LogicalTableScan(table=[[t2]])
> {code}
> Based on the converted plan, result is 4; while the correct answer is 2.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2249) AggregateJoinTransposeRule generates inequivalent nodes if Aggregate relNode contains distinct aggregate function.
[
https://issues.apache.org/jira/browse/CALCITE-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433544#comment-16433544
]
Julian Hyde commented on CALCITE-2249:
--
Yes, and use a predicate (similar to Aggregate.IS_SIMPLE) to bail out before
the rule is even matched.
> AggregateJoinTransposeRule generates inequivalent nodes if Aggregate relNode
> contains distinct aggregate function.
> --
>
> Key: CALCITE-2249
> URL: https://issues.apache.org/jira/browse/CALCITE-2249
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: jingzhang
>Assignee: Julian Hyde
>Priority: Major
>
> AggregateJoinTransposeRule generates inequivalent nodes if Aggregate relNode
> contains distinct aggregate function.
> T1
> ||a (String)||b (int)||
> |A|1|
> |A|2|
> |B|2|
> |C|3|
>
> T2
> ||c(int)||
> |1|
> |1|
> |2|
> For the following sql,
> {code:java}
> select count (distinct a) from t1, t2 where t1.b = t2.c
> {code}
> Aggregate would generate following node tree, which is inequivalent with
> original node tree.
> {code:java}
> LogicalAggregate(group=[{}], EXPR$0=[$SUM0($4)])
> +- LogicalProject(b=[$0], EXPR$0=[$1], c=[$2], $f1=[$3], $f4=[*($1, $3)])
> +- LogicalJoin(condition=[=($0, $2)], joinType=[inner])
> :- LogicalAggregate(group=[\{1}], EXPR$0=[COUNT(DISTINCT $0)])
> : +- LogicalTableScan(table=[[t1]])
> +- LogicalAggregate(group=[\{0}], agg#0=[COUNT()])
> +- LogicalTableScan(table=[[t2]])
> {code}
> Based on the converted plan, result is 4; while the correct answer is 2.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CALCITE-2206) JDBC adapter incorrectly pushes windowed aggregates down to HSQLDB
[
https://issues.apache.org/jira/browse/CALCITE-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-2206.
--
Resolution: Fixed
Fix Version/s: 1.17.0
Fixed in
[502c1084|http://git-wip-us.apache.org/repos/asf/calcite/commit/502c1084];
thanks for the PR, [~Pavel Gubin]!
> JDBC adapter incorrectly pushes windowed aggregates down to HSQLDB
> --
>
> Key: CALCITE-2206
> URL: https://issues.apache.org/jira/browse/CALCITE-2206
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.15.0
>Reporter: Pavel Gubin
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> JDBC adapter incorrectly pushes windowed aggregates down to HSQLDB. Queries
> containing window functions fail when using HSQLDB (or any other DB that does
> not support window functions) because the optimizer converts them to native
> SQL with window functions which are not supported by HSQLDB. For example:
> {code:sql}
> select "store_id", "product_id", sum("unit_sales") unit_sales, row_number()
> over (
> partition by "store_id" order by sum("unit_sales") desc
> ) row_num
> from "sales_fact_1998"
> group by "store_id", "product_id"
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2249) AggregateJoinTransposeRule generates inequivalent nodes if Aggregate relNode contains distinct aggregate function.
[
https://issues.apache.org/jira/browse/CALCITE-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433540#comment-16433540
]
Haisheng Yuan commented on CALCITE-2249:
We can bail out for distinct aggregation.
> AggregateJoinTransposeRule generates inequivalent nodes if Aggregate relNode
> contains distinct aggregate function.
> --
>
> Key: CALCITE-2249
> URL: https://issues.apache.org/jira/browse/CALCITE-2249
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: jingzhang
>Assignee: Julian Hyde
>Priority: Major
>
> AggregateJoinTransposeRule generates inequivalent nodes if Aggregate relNode
> contains distinct aggregate function.
> T1
> ||a (String)||b (int)||
> |A|1|
> |A|2|
> |B|2|
> |C|3|
>
> T2
> ||c(int)||
> |1|
> |1|
> |2|
> For the following sql,
> {code:java}
> select count (distinct a) from t1, t2 where t1.b = t2.c
> {code}
> Aggregate would generate following node tree, which is inequivalent with
> original node tree.
> {code:java}
> LogicalAggregate(group=[{}], EXPR$0=[$SUM0($4)])
> +- LogicalProject(b=[$0], EXPR$0=[$1], c=[$2], $f1=[$3], $f4=[*($1, $3)])
> +- LogicalJoin(condition=[=($0, $2)], joinType=[inner])
> :- LogicalAggregate(group=[\{1}], EXPR$0=[COUNT(DISTINCT $0)])
> : +- LogicalTableScan(table=[[t1]])
> +- LogicalAggregate(group=[\{0}], agg#0=[COUNT()])
> +- LogicalTableScan(table=[[t2]])
> {code}
> Based on the converted plan, result is 4; while the correct answer is 2.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CALCITE-2237) JDK 10 builds fail with NPE due to SUREFIRE-1439
[ https://issues.apache.org/jira/browse/CALCITE-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde resolved CALCITE-2237. -- Resolution: Fixed Fixed in [000622da|http://git-wip-us.apache.org/repos/asf/calcite/commit/000622da]; thanks for the PR, [~risdenk]! > JDK 10 builds fail with NPE due to SUREFIRE-1439 > > > Key: CALCITE-2237 > URL: https://issues.apache.org/jira/browse/CALCITE-2237 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.17.0 >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: 1.17.0 > > > SUREFIRE-1439 causes an NPE when using JDK 10. CALCITE-2225 upgraded to > Apache parent pom 19 which included Surefire 2.20.1. MPOM-184 is tracking the > fix for Apache parent pom 20. We should update to Surefire 2.21.0 to ensure > that builds function on JDK 10. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2249) AggregateJoinTransposeRule generates inequivalent nodes if Aggregate relNode contains distinct aggregate function.
jingzhang created CALCITE-2249:
--
Summary: AggregateJoinTransposeRule generates inequivalent nodes
if Aggregate relNode contains distinct aggregate function.
Key: CALCITE-2249
URL: https://issues.apache.org/jira/browse/CALCITE-2249
Project: Calcite
Issue Type: Bug
Components: core
Reporter: jingzhang
Assignee: Julian Hyde
AggregateJoinTransposeRule generates inequivalent nodes if Aggregate relNode
contains distinct aggregate function.
T1
||a (String)||b (int)||
|A|1|
|A|2|
|B|2|
|C|3|
T2
||c(int)||
|1|
|1|
|2|
For the following sql,
${code}
select count (distinct a) from t1, t2 where t1.b = t2.c
${code}
Aggregate would generate following node tree, which is inequivalent with
original node tree.
${code}
LogicalAggregate(group=[{}], EXPR$0=[$SUM0($4)])
+- LogicalProject(b=[$0], EXPR$0=[$1], c=[$2], $f1=[$3], $f4=[*($1, $3)])
+- LogicalJoin(condition=[=($0, $2)], joinType=[inner])
:- LogicalAggregate(group=[\{1}], EXPR$0=[COUNT(DISTINCT $0)])
: +- LogicalTableScan(table=[[t1]])
+- LogicalAggregate(group=[\{0}], agg#0=[COUNT()])
+- LogicalTableScan(table=[[t2]])
${code}
Based on the converted plan, result is 4; while the correct answer is 2.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2206) JDBC adapter incorrectly pushes windowed aggregates down to HSQLDB
[
https://issues.apache.org/jira/browse/CALCITE-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-2206:
-
Description:
JDBC adapter incorrectly pushes windowed aggregates down to HSQLDB. Queries
containing window functions fail when using HSQLDB (or any other DB that does
not support window functions) because the optimizer converts them to native SQL
with window functions which are not supported by HSQLDB. For example:
{code:sql}
select "store_id", "product_id", sum("unit_sales") unit_sales, row_number()
over (
partition by "store_id" order by sum("unit_sales") desc
) row_num
from "sales_fact_1998"
group by "store_id", "product_id"
{code}
was:
Queries containing window functions fail when using HSQLDB (or any other DB
that does not support window functions) because optimiser converts them to
native SQL with window functions which are not supported by HSQLDB. For example:
{code:sql}
select "store_id", "product_id", sum("unit_sales") unit_sales, row_number()
over (
partition by "store_id" order by sum("unit_sales") desc
) row_num
from "sales_fact_1998"
group by "store_id", "product_id"
{code}
> JDBC adapter incorrectly pushes windowed aggregates down to HSQLDB
> --
>
> Key: CALCITE-2206
> URL: https://issues.apache.org/jira/browse/CALCITE-2206
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.15.0
>Reporter: Pavel Gubin
>Assignee: Julian Hyde
>Priority: Major
>
> JDBC adapter incorrectly pushes windowed aggregates down to HSQLDB. Queries
> containing window functions fail when using HSQLDB (or any other DB that does
> not support window functions) because the optimizer converts them to native
> SQL with window functions which are not supported by HSQLDB. For example:
> {code:sql}
> select "store_id", "product_id", sum("unit_sales") unit_sales, row_number()
> over (
> partition by "store_id" order by sum("unit_sales") desc
> ) row_num
> from "sales_fact_1998"
> group by "store_id", "product_id"
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2206) JDBC adapter incorrectly pushes windowed aggregates down to HSQLDB
[
https://issues.apache.org/jira/browse/CALCITE-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-2206:
-
Summary: JDBC adapter incorrectly pushes windowed aggregates down to HSQLDB
(was: Queries with window functions fail when using HSQLDB)
> JDBC adapter incorrectly pushes windowed aggregates down to HSQLDB
> --
>
> Key: CALCITE-2206
> URL: https://issues.apache.org/jira/browse/CALCITE-2206
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.15.0
>Reporter: Pavel Gubin
>Assignee: Julian Hyde
>Priority: Major
>
> Queries containing window functions fail when using HSQLDB (or any other DB
> that does not support window functions) because optimiser converts them to
> native SQL with window functions which are not supported by HSQLDB. For
> example:
> {code:sql}
> select "store_id", "product_id", sum("unit_sales") unit_sales, row_number()
> over (
> partition by "store_id" order by sum("unit_sales") desc
> ) row_num
> from "sales_fact_1998"
> group by "store_id", "product_id"
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
