[jira] [Commented] (CALCITE-2703) Reduce code generation and class loading overhead when executing queries in the EnumerableConvention
[ https://issues.apache.org/jira/browse/CALCITE-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16697373#comment-16697373 ] Julian Hyde commented on CALCITE-2703: -- Let’s be careful. You’re adding a layer of caching in production code path to make the test suite run faster. Test query patterns are not like production patterns. Are you optimizing the wrong thing? > Reduce code generation and class loading overhead when executing queries in > the EnumerableConvention > > > Key: CALCITE-2703 > URL: https://issues.apache.org/jira/browse/CALCITE-2703 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.17.0 >Reporter: Stamatis Zampetakis >Assignee: Julian Hyde >Priority: Major > Labels: performance > Fix For: 1.18.0 > > > The queries using Calcite's EnumerableConvention always end-up generating new > java classes at runtime (using Janino) that are then instantiated using > reflection. This combination of class generation and class loading introduces > a big overhead in query response time. > A quick profiling on our Company's internal test suite consisting in 4000 > tests with roughly 43 SQL queries passing through Calcite we observed > that a big amount of time is spend on code generation and class loading > making the EnumerableInterpretable#toBindable method a performance > bottleneck. > Among the 43 SQL queries there are many duplicates which are going to > lead to the generation of exactly the same code Java. Introducing, a small > cache at the level of EnumerableInterpretable class could avoid generating > and loading the same code over and over again. > A simple implementation based on Guava improved the overall execution time of > the afforementioned test suite by more than 50%. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2699) The bug of timestampadd handles time
[
https://issues.apache.org/jira/browse/CALCITE-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16697317#comment-16697317
]
xuqianjin edited comment on CALCITE-2699 at 11/23/18 4:43 PM:
--
[~julianhyde] [~vlsi] I have submitted PR. Can you give me this isuse
permission to add PR links
https://github.com/apache/calcite/pull/936
was (Author: x1q1j1):
[~julianhyde] [~vlsi] I have submitted PR. Can you give me this isuse
permission to add PR links
> The bug of timestampadd handles time
> -
>
> Key: CALCITE-2699
> URL: https://issues.apache.org/jira/browse/CALCITE-2699
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0, 1.18.0
>Reporter: xuqianjin
>Assignee: Julian Hyde
>Priority: Major
>
> Two errors occur when {{timestampadd(MINUTE, 1, time '01:00:00')}} is
> executed:
> # The return result can only be of {{TimeStamp}} type and is expected to be
> of {{Time}} type
> # The return value is {{1970-01-01 01:01:00}}, and the expectation is
> {{01:01:00}}
> # I think it should meet the following conditions:
> ||expression||Expect the result||
> |timestampadd(MINUTE, -1, time '00:00:00')|23:59:00|
> |timestampadd(MINUTE, 1, time '00:00:00')|00:01:00|
> |timestampadd(MINUTE, 1, time '23:59:59')|00:00:59|
> |timestampadd(SECOND, 1, time '23:59:59')|00:00:00|
> |timestampadd(HOUR, 1, time '23:59:59')|00:59:59|
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2699) The bug of timestampadd handles time
[
https://issues.apache.org/jira/browse/CALCITE-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16697130#comment-16697130
]
xuqianjin edited comment on CALCITE-2699 at 11/23/18 4:24 PM:
--
[~kgyrtkirk] Thank you very much. Your conclusion is correct. Null is due to my
mysql connection to the client.I've changed it
was (Author: x1q1j1):
[~kgyrtkirk] Thank you very much. Your conclusion is correct. Null is due to my
mysql connection to the client.I've changed it
> The bug of timestampadd handles time
> -
>
> Key: CALCITE-2699
> URL: https://issues.apache.org/jira/browse/CALCITE-2699
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0, 1.18.0
>Reporter: xuqianjin
>Assignee: Julian Hyde
>Priority: Major
>
> Two errors occur when {{timestampadd(MINUTE, 1, time '01:00:00')}} is
> executed:
> # The return result can only be of {{TimeStamp}} type and is expected to be
> of {{Time}} type
> # The return value is {{1970-01-01 01:01:00}}, and the expectation is
> {{01:01:00}}
> # I think it should meet the following conditions:
> ||expression||Expect the result||
> |timestampadd(MINUTE, -1, time '00:00:00')|23:59:00|
> |timestampadd(MINUTE, 1, time '00:00:00')|00:01:00|
> |timestampadd(MINUTE, 1, time '23:59:59')|00:00:59|
> |timestampadd(SECOND, 1, time '23:59:59')|00:00:00|
> |timestampadd(HOUR, 1, time '23:59:59')|00:59:59|
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2699) The bug of timestampadd handles time
[
https://issues.apache.org/jira/browse/CALCITE-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16697317#comment-16697317
]
xuqianjin commented on CALCITE-2699:
[~julianhyde] [~vlsi] I have submitted PR. Can you give me this isuse
permission to add PR links
> The bug of timestampadd handles time
> -
>
> Key: CALCITE-2699
> URL: https://issues.apache.org/jira/browse/CALCITE-2699
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0, 1.18.0
>Reporter: xuqianjin
>Assignee: Julian Hyde
>Priority: Major
>
> Two errors occur when {{timestampadd(MINUTE, 1, time '01:00:00')}} is
> executed:
> # The return result can only be of {{TimeStamp}} type and is expected to be
> of {{Time}} type
> # The return value is {{1970-01-01 01:01:00}}, and the expectation is
> {{01:01:00}}
> # I think it should meet the following conditions:
> ||expression||Expect the result||
> |timestampadd(MINUTE, -1, time '00:00:00')|23:59:00|
> |timestampadd(MINUTE, 1, time '00:00:00')|00:01:00|
> |timestampadd(MINUTE, 1, time '23:59:59')|00:00:59|
> |timestampadd(SECOND, 1, time '23:59:59')|00:00:00|
> |timestampadd(HOUR, 1, time '23:59:59')|00:59:59|
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2703) Reduce code generation and class loading overhead when executing queries in the EnumerableConvention
[ https://issues.apache.org/jira/browse/CALCITE-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16697316#comment-16697316 ] Vladimir Sitnikov commented on CALCITE-2703: I mean cache in Calcite's implementation of PreparedStatement. PS. EnumerableInterpretable should probably just interpret things without code generation. Am I missing something? > Reduce code generation and class loading overhead when executing queries in > the EnumerableConvention > > > Key: CALCITE-2703 > URL: https://issues.apache.org/jira/browse/CALCITE-2703 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.17.0 >Reporter: Stamatis Zampetakis >Assignee: Julian Hyde >Priority: Major > Labels: performance > Fix For: 1.18.0 > > > The queries using Calcite's EnumerableConvention always end-up generating new > java classes at runtime (using Janino) that are then instantiated using > reflection. This combination of class generation and class loading introduces > a big overhead in query response time. > A quick profiling on our Company's internal test suite consisting in 4000 > tests with roughly 43 SQL queries passing through Calcite we observed > that a big amount of time is spend on code generation and class loading > making the EnumerableInterpretable#toBindable method a performance > bottleneck. > Among the 43 SQL queries there are many duplicates which are going to > lead to the generation of exactly the same code Java. Introducing, a small > cache at the level of EnumerableInterpretable class could avoid generating > and loading the same code over and over again. > A simple implementation based on Guava improved the overall execution time of > the afforementioned test suite by more than 50%. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2699) The bug of timestampadd handles time
[
https://issues.apache.org/jira/browse/CALCITE-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
xuqianjin updated CALCITE-2699:
---
Docs Text: https://github.com/apache/calcite/pull/936
External issue URL: (was: https://github.com/apache/calcite/pull/936)
> The bug of timestampadd handles time
> -
>
> Key: CALCITE-2699
> URL: https://issues.apache.org/jira/browse/CALCITE-2699
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0, 1.18.0
>Reporter: xuqianjin
>Assignee: Julian Hyde
>Priority: Major
>
> Two errors occur when {{timestampadd(MINUTE, 1, time '01:00:00')}} is
> executed:
> # The return result can only be of {{TimeStamp}} type and is expected to be
> of {{Time}} type
> # The return value is {{1970-01-01 01:01:00}}, and the expectation is
> {{01:01:00}}
> # I think it should meet the following conditions:
> ||expression||Expect the result||
> |timestampadd(MINUTE, -1, time '00:00:00')|23:59:00|
> |timestampadd(MINUTE, 1, time '00:00:00')|00:01:00|
> |timestampadd(MINUTE, 1, time '23:59:59')|00:00:59|
> |timestampadd(SECOND, 1, time '23:59:59')|00:00:00|
> |timestampadd(HOUR, 1, time '23:59:59')|00:59:59|
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2699) The bug of timestampadd handles time
[
https://issues.apache.org/jira/browse/CALCITE-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
xuqianjin updated CALCITE-2699:
---
Docs Text: (was: https://github.com/apache/calcite/pull/936)
> The bug of timestampadd handles time
> -
>
> Key: CALCITE-2699
> URL: https://issues.apache.org/jira/browse/CALCITE-2699
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0, 1.18.0
>Reporter: xuqianjin
>Assignee: Julian Hyde
>Priority: Major
>
> Two errors occur when {{timestampadd(MINUTE, 1, time '01:00:00')}} is
> executed:
> # The return result can only be of {{TimeStamp}} type and is expected to be
> of {{Time}} type
> # The return value is {{1970-01-01 01:01:00}}, and the expectation is
> {{01:01:00}}
> # I think it should meet the following conditions:
> ||expression||Expect the result||
> |timestampadd(MINUTE, -1, time '00:00:00')|23:59:00|
> |timestampadd(MINUTE, 1, time '00:00:00')|00:01:00|
> |timestampadd(MINUTE, 1, time '23:59:59')|00:00:59|
> |timestampadd(SECOND, 1, time '23:59:59')|00:00:00|
> |timestampadd(HOUR, 1, time '23:59:59')|00:59:59|
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2699) The bug of timestampadd handles time
[
https://issues.apache.org/jira/browse/CALCITE-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
xuqianjin updated CALCITE-2699:
---
External issue URL: https://github.com/apache/calcite/pull/936
> The bug of timestampadd handles time
> -
>
> Key: CALCITE-2699
> URL: https://issues.apache.org/jira/browse/CALCITE-2699
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0, 1.18.0
>Reporter: xuqianjin
>Assignee: Julian Hyde
>Priority: Major
>
> Two errors occur when {{timestampadd(MINUTE, 1, time '01:00:00')}} is
> executed:
> # The return result can only be of {{TimeStamp}} type and is expected to be
> of {{Time}} type
> # The return value is {{1970-01-01 01:01:00}}, and the expectation is
> {{01:01:00}}
> # I think it should meet the following conditions:
> ||expression||Expect the result||
> |timestampadd(MINUTE, -1, time '00:00:00')|23:59:00|
> |timestampadd(MINUTE, 1, time '00:00:00')|00:01:00|
> |timestampadd(MINUTE, 1, time '23:59:59')|00:00:59|
> |timestampadd(SECOND, 1, time '23:59:59')|00:00:00|
> |timestampadd(HOUR, 1, time '23:59:59')|00:59:59|
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2703) Reduce code generation and class loading overhead when executing queries in the EnumerableConvention
[ https://issues.apache.org/jira/browse/CALCITE-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16697297#comment-16697297 ] Stamatis Zampetakis commented on CALCITE-2703: -- I am not using Calcite as a server so I am not passing at all through the PreparedStatement infrustructure. It is totally feasible to add a cache at a higher level (without even touching Calcite code) but I would rather do it in EnumerableInterpretable class so that everybody can benefit of it. > Reduce code generation and class loading overhead when executing queries in > the EnumerableConvention > > > Key: CALCITE-2703 > URL: https://issues.apache.org/jira/browse/CALCITE-2703 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.17.0 >Reporter: Stamatis Zampetakis >Assignee: Julian Hyde >Priority: Major > Labels: performance > Fix For: 1.18.0 > > > The queries using Calcite's EnumerableConvention always end-up generating new > java classes at runtime (using Janino) that are then instantiated using > reflection. This combination of class generation and class loading introduces > a big overhead in query response time. > A quick profiling on our Company's internal test suite consisting in 4000 > tests with roughly 43 SQL queries passing through Calcite we observed > that a big amount of time is spend on code generation and class loading > making the EnumerableInterpretable#toBindable method a performance > bottleneck. > Among the 43 SQL queries there are many duplicates which are going to > lead to the generation of exactly the same code Java. Introducing, a small > cache at the level of EnumerableInterpretable class could avoid generating > and loading the same code over and over again. > A simple implementation based on Guava improved the overall execution time of > the afforementioned test suite by more than 50%. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2703) Reduce code generation and class loading overhead when executing queries in the EnumerableConvention
[ https://issues.apache.org/jira/browse/CALCITE-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16697287#comment-16697287 ] Vladimir Sitnikov commented on CALCITE-2703: [~zabetak], have you checked the original SQL statements? I wonder if caching at the level of "PreparedStatement" would be better. > Reduce code generation and class loading overhead when executing queries in > the EnumerableConvention > > > Key: CALCITE-2703 > URL: https://issues.apache.org/jira/browse/CALCITE-2703 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.17.0 >Reporter: Stamatis Zampetakis >Assignee: Julian Hyde >Priority: Major > Labels: performance > Fix For: 1.18.0 > > > The queries using Calcite's EnumerableConvention always end-up generating new > java classes at runtime (using Janino) that are then instantiated using > reflection. This combination of class generation and class loading introduces > a big overhead in query response time. > A quick profiling on our Company's internal test suite consisting in 4000 > tests with roughly 43 SQL queries passing through Calcite we observed > that a big amount of time is spend on code generation and class loading > making the EnumerableInterpretable#toBindable method a performance > bottleneck. > Among the 43 SQL queries there are many duplicates which are going to > lead to the generation of exactly the same code Java. Introducing, a small > cache at the level of EnumerableInterpretable class could avoid generating > and loading the same code over and over again. > A simple implementation based on Guava improved the overall execution time of > the afforementioned test suite by more than 50%. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2703) Reduce code generation and class loading overhead when executing queries in the EnumerableConvention
Stamatis Zampetakis created CALCITE-2703: Summary: Reduce code generation and class loading overhead when executing queries in the EnumerableConvention Key: CALCITE-2703 URL: https://issues.apache.org/jira/browse/CALCITE-2703 Project: Calcite Issue Type: Improvement Components: core Affects Versions: 1.17.0 Reporter: Stamatis Zampetakis Assignee: Julian Hyde Fix For: 1.18.0 The queries using Calcite's EnumerableConvention always end-up generating new java classes at runtime (using Janino) that are then instantiated using reflection. This combination of class generation and class loading introduces a big overhead in query response time. A quick profiling on our Company's internal test suite consisting in 4000 tests with roughly 43 SQL queries passing through Calcite we observed that a big amount of time is spend on code generation and class loading making the EnumerableInterpretable#toBindable method a performance bottleneck. Among the 43 SQL queries there are many duplicates which are going to lead to the generation of exactly the same code Java. Introducing, a small cache at the level of EnumerableInterpretable class could avoid generating and loading the same code over and over again. A simple implementation based on Guava improved the overall execution time of the afforementioned test suite by more than 50%. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2702) Invalid commit()/rollback() behavior on JDBC connection
Dirk Mahler created CALCITE-2702:
Summary: Invalid commit()/rollback() behavior on JDBC connection
Key: CALCITE-2702
URL: https://issues.apache.org/jira/browse/CALCITE-2702
Project: Calcite
Issue Type: Bug
Components: jdbc-adapter
Affects Versions: 1.17.0
Reporter: Dirk Mahler
Assignee: Julian Hyde
We're using Tibco Spotfire with a Calcite enabled JDBC driver as a pooled
datasource. There is an issue that the Spotfire connection pool rans out of
connections quite fast and we could track it down to the behavior of
org.apache.calcite.avatica.AvaticaConnection#commit. This delegates to
org.apache.calcite.jdbc.CalciteMetaImpl#commit which throws an
UnsupportedOperationException.
It looks like that this behavior is not correct: according to the JavaDoc of
java.sql.DatabaseMetaData#supportsTransactions a JDBC driver should treat
commit as a NOOP if the database (or in this case the driver) does not support
transactions:
{noformat}
/**
* Retrieves whether this database supports transactions. If not, invoking the
* method commit is a noop, and the isolation level is
* TRANSACTION_NONE.
*
* @return true if transactions are supported;
* false otherwise
* @exception SQLException if a database access error occurs
*/
boolean supportsTransactions() throws SQLException;{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2699) The bug of timestampadd handles time
[
https://issues.apache.org/jira/browse/CALCITE-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
xuqianjin updated CALCITE-2699:
---
Description:
Two errors occur when {{timestampadd(MINUTE, 1, time '01:00:00')}} is executed:
# The return result can only be of {{TimeStamp}} type and is expected to be of
{{Time}} type
# The return value is {{1970-01-01 01:01:00}}, and the expectation is
{{01:01:00}}
# I think it should meet the following conditions:
||expression||Expect the result||
|timestampadd(MINUTE, -1, time '00:00:00')|23:59:00|
|timestampadd(MINUTE, 1, time '00:00:00')|00:01:00|
|timestampadd(MINUTE, 1, time '23:59:59')|00:00:59|
|timestampadd(SECOND, 1, time '23:59:59')|00:00:00|
|timestampadd(HOUR, 1, time '23:59:59')|00:59:59|
was:
Two errors occur when {{timestampadd(MINUTE, 1, time '01:00:00')}} is executed:
# The return result can only be of {{TimeStamp}} type and is expected to be of
{{Time}} type
# The return value is {{1970-01-01 01:01:00}}, and the expectation is
{{01:01:00}}
# Compared with {{mysql}} database, I think it should meet the following
conditions:
||expression||Expect the result||
|timestampadd(MINUTE, -1, time '00:00:00')|23:59:00|
|timestampadd(MINUTE, 1, time '00:00:00')|00:01:00|
|timestampadd(MINUTE, 1, time '23:59:59')|00:00:59|
|timestampadd(SECOND, 1, time '23:59:59')|00:00:00|
|timestampadd(HOUR, 1, time '23:59:59')|00:59:59|
> The bug of timestampadd handles time
> -
>
> Key: CALCITE-2699
> URL: https://issues.apache.org/jira/browse/CALCITE-2699
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0, 1.18.0
>Reporter: xuqianjin
>Assignee: Julian Hyde
>Priority: Major
>
> Two errors occur when {{timestampadd(MINUTE, 1, time '01:00:00')}} is
> executed:
> # The return result can only be of {{TimeStamp}} type and is expected to be
> of {{Time}} type
> # The return value is {{1970-01-01 01:01:00}}, and the expectation is
> {{01:01:00}}
> # I think it should meet the following conditions:
> ||expression||Expect the result||
> |timestampadd(MINUTE, -1, time '00:00:00')|23:59:00|
> |timestampadd(MINUTE, 1, time '00:00:00')|00:01:00|
> |timestampadd(MINUTE, 1, time '23:59:59')|00:00:59|
> |timestampadd(SECOND, 1, time '23:59:59')|00:00:00|
> |timestampadd(HOUR, 1, time '23:59:59')|00:59:59|
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2699) The bug of timestampadd handles time
[
https://issues.apache.org/jira/browse/CALCITE-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
xuqianjin updated CALCITE-2699:
---
Description:
Two errors occur when {{timestampadd(MINUTE, 1, time '01:00:00')}} is executed:
# The return result can only be of {{TimeStamp}} type and is expected to be of
{{Time}} type
# The return value is {{1970-01-01 01:01:00}}, and the expectation is
{{01:01:00}}
# Compared with {{mysql}} database, I think it should meet the following
conditions:
||expression||Expect the result||
|timestampadd(MINUTE, -1, time '00:00:00')|23:59:00|
|timestampadd(MINUTE, 1, time '00:00:00')|00:01:00|
|timestampadd(MINUTE, 1, time '23:59:59')|00:00:59|
|timestampadd(SECOND, 1, time '23:59:59')|00:00:00|
|timestampadd(HOUR, 1, time '23:59:59')|00:59:59|
was:
Two errors occur when {{timestampadd(MINUTE, 1, time '01:00:00')}} is executed:
# The return result can only be of {{TimeStamp}} type and is expected to be of
{{Time}} type
# The return value is {{1970-01-01 01:01:00}}, and the expectation is
{{01:01:00}}
# Compared with {{mysql}} database, I think it should meet the following
conditions:
||expression||Expect the result||
|timestampadd(MINUTE, -1, time '00:00:00')|-00:01:00|
|timestampadd(MINUTE, 1, time '00:00:00')|00:01:00|
|timestampadd(MINUTE, 1, time '23:59:59')| 24:00:59|
|timestampadd(SECOND, 1, time '23:59:59')|24:00:00|
|timestampadd(HOUR, 1, time '23:59:59')|24:59:59|
> The bug of timestampadd handles time
> -
>
> Key: CALCITE-2699
> URL: https://issues.apache.org/jira/browse/CALCITE-2699
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0, 1.18.0
>Reporter: xuqianjin
>Assignee: Julian Hyde
>Priority: Major
>
> Two errors occur when {{timestampadd(MINUTE, 1, time '01:00:00')}} is
> executed:
> # The return result can only be of {{TimeStamp}} type and is expected to be
> of {{Time}} type
> # The return value is {{1970-01-01 01:01:00}}, and the expectation is
> {{01:01:00}}
> # Compared with {{mysql}} database, I think it should meet the following
> conditions:
> ||expression||Expect the result||
> |timestampadd(MINUTE, -1, time '00:00:00')|23:59:00|
> |timestampadd(MINUTE, 1, time '00:00:00')|00:01:00|
> |timestampadd(MINUTE, 1, time '23:59:59')|00:00:59|
> |timestampadd(SECOND, 1, time '23:59:59')|00:00:00|
> |timestampadd(HOUR, 1, time '23:59:59')|00:59:59|
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2699) The bug of timestampadd handles time
[
https://issues.apache.org/jira/browse/CALCITE-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
xuqianjin updated CALCITE-2699:
---
Description:
Two errors occur when {{timestampadd(MINUTE, 1, time '01:00:00')}} is executed:
# The return result can only be of {{TimeStamp}} type and is expected to be of
{{Time}} type
# The return value is {{1970-01-01 01:01:00}}, and the expectation is
{{01:01:00}}
# Compared with {{mysql}} database, I think it should meet the following
conditions:
||expression||Expect the result||
|timestampadd(MINUTE, -1, time '00:00:00')|-00:01:00|
|timestampadd(MINUTE, 1, time '00:00:00')|00:01:00|
|timestampadd(MINUTE, 1, time '23:59:59')| 24:00:59|
|timestampadd(SECOND, 1, time '23:59:59')|24:00:00|
|timestampadd(HOUR, 1, time '23:59:59')|24:59:59|
was:
Two errors occur when {{timestampadd(MINUTE, 1, time '01:00:00')}} is executed:
# The return result can only be of {{TimeStamp}} type and is expected to be of
{{Time}} type
# The return value is {{1970-01-01 01:01:00}}, and the expectation is
{{01:01:00}}
# Compared with {{mysql}} database, I think it should meet the following
conditions:
||expression||Expect the result||
|timestampadd(MINUTE, -1, time '00:00:00')|-00:01:00|
|timestampadd(MINUTE, 1, time '00:00:00')|00:01:00|
|timestampadd(MINUTE, 1, time '23:59:59')|00:00:59|
|timestampadd(SECOND, 1, time '23:59:59')|00:00:00|
|timestampadd(HOUR, 1, time '23:59:59')|00:59:59|
> The bug of timestampadd handles time
> -
>
> Key: CALCITE-2699
> URL: https://issues.apache.org/jira/browse/CALCITE-2699
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0, 1.18.0
>Reporter: xuqianjin
>Assignee: Julian Hyde
>Priority: Major
>
> Two errors occur when {{timestampadd(MINUTE, 1, time '01:00:00')}} is
> executed:
> # The return result can only be of {{TimeStamp}} type and is expected to be
> of {{Time}} type
> # The return value is {{1970-01-01 01:01:00}}, and the expectation is
> {{01:01:00}}
> # Compared with {{mysql}} database, I think it should meet the following
> conditions:
> ||expression||Expect the result||
> |timestampadd(MINUTE, -1, time '00:00:00')|-00:01:00|
> |timestampadd(MINUTE, 1, time '00:00:00')|00:01:00|
> |timestampadd(MINUTE, 1, time '23:59:59')| 24:00:59|
> |timestampadd(SECOND, 1, time '23:59:59')|24:00:00|
> |timestampadd(HOUR, 1, time '23:59:59')|24:59:59|
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2699) The bug of timestampadd handles time
[
https://issues.apache.org/jira/browse/CALCITE-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
xuqianjin updated CALCITE-2699:
---
Description:
Two errors occur when {{timestampadd(MINUTE, 1, time '01:00:00')}} is executed:
# The return result can only be of {{TimeStamp}} type and is expected to be of
{{Time}} type
# The return value is {{1970-01-01 01:01:00}}, and the expectation is
{{01:01:00}}
# Compared with {{mysql}} database, I think it should meet the following
conditions:
||expression||Expect the result||
|timestampadd(MINUTE, -1, time '00:00:00')|-00:01:00|
|timestampadd(MINUTE, 1, time '00:00:00')|00:01:00|
|timestampadd(MINUTE, 1, time '23:59:59')|00:00:59|
|timestampadd(SECOND, 1, time '23:59:59')|00:00:00|
|timestampadd(HOUR, 1, time '23:59:59')|00:59:59|
was:
Two errors occur when {{timestampadd(MINUTE, 1, time '01:00:00')}} is executed:
# The return result can only be of {{TimeStamp}} type and is expected to be of
{{Time}} type
# The return value is {{1970-01-01 01:01:00}}, and the expectation is
{{01:01:00}}
# Compared with {{mysql}} database, I think it should meet the following
conditions:
||expression||Expect the result||
|timestampadd(MINUTE, -1, time '00:00:00')|NULL|
|timestampadd(MINUTE, 1, time '00:00:00')|00:01:00|
|timestampadd(MINUTE, 1, time '23:59:59')|00:00:59|
|timestampadd(SECOND, 1, time '23:59:59')|00:00:00|
|timestampadd(HOUR, 1, time '23:59:59')|00:59:59|
> The bug of timestampadd handles time
> -
>
> Key: CALCITE-2699
> URL: https://issues.apache.org/jira/browse/CALCITE-2699
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0, 1.18.0
>Reporter: xuqianjin
>Assignee: Julian Hyde
>Priority: Major
>
> Two errors occur when {{timestampadd(MINUTE, 1, time '01:00:00')}} is
> executed:
> # The return result can only be of {{TimeStamp}} type and is expected to be
> of {{Time}} type
> # The return value is {{1970-01-01 01:01:00}}, and the expectation is
> {{01:01:00}}
> # Compared with {{mysql}} database, I think it should meet the following
> conditions:
> ||expression||Expect the result||
> |timestampadd(MINUTE, -1, time '00:00:00')|-00:01:00|
> |timestampadd(MINUTE, 1, time '00:00:00')|00:01:00|
> |timestampadd(MINUTE, 1, time '23:59:59')|00:00:59|
> |timestampadd(SECOND, 1, time '23:59:59')|00:00:00|
> |timestampadd(HOUR, 1, time '23:59:59')|00:59:59|
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2699) The bug of timestampadd handles time
[
https://issues.apache.org/jira/browse/CALCITE-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16697130#comment-16697130
]
xuqianjin edited comment on CALCITE-2699 at 11/23/18 1:28 PM:
--
[~kgyrtkirk] Thank you very much. Your conclusion is correct. Null is due to my
mysql connection to the client.I've changed it
was (Author: x1q1j1):
[~kgyrtkirk] Your conclusion is correct. Null is due to my mysql connection to
the client.I've changed it
> The bug of timestampadd handles time
> -
>
> Key: CALCITE-2699
> URL: https://issues.apache.org/jira/browse/CALCITE-2699
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0, 1.18.0
>Reporter: xuqianjin
>Assignee: Julian Hyde
>Priority: Major
>
> Two errors occur when {{timestampadd(MINUTE, 1, time '01:00:00')}} is
> executed:
> # The return result can only be of {{TimeStamp}} type and is expected to be
> of {{Time}} type
> # The return value is {{1970-01-01 01:01:00}}, and the expectation is
> {{01:01:00}}
> # Compared with {{mysql}} database, I think it should meet the following
> conditions:
> ||expression||Expect the result||
> |timestampadd(MINUTE, -1, time '00:00:00')|-00:01:00|
> |timestampadd(MINUTE, 1, time '00:00:00')|00:01:00|
> |timestampadd(MINUTE, 1, time '23:59:59')|00:00:59|
> |timestampadd(SECOND, 1, time '23:59:59')|00:00:00|
> |timestampadd(HOUR, 1, time '23:59:59')|00:59:59|
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2699) The bug of timestampadd handles time
[
https://issues.apache.org/jira/browse/CALCITE-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16697130#comment-16697130
]
xuqianjin commented on CALCITE-2699:
[~kgyrtkirk] Your conclusion is correct. Null is due to my mysql connection to
the client.I've changed it
> The bug of timestampadd handles time
> -
>
> Key: CALCITE-2699
> URL: https://issues.apache.org/jira/browse/CALCITE-2699
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0, 1.18.0
>Reporter: xuqianjin
>Assignee: Julian Hyde
>Priority: Major
>
> Two errors occur when {{timestampadd(MINUTE, 1, time '01:00:00')}} is
> executed:
> # The return result can only be of {{TimeStamp}} type and is expected to be
> of {{Time}} type
> # The return value is {{1970-01-01 01:01:00}}, and the expectation is
> {{01:01:00}}
> # Compared with {{mysql}} database, I think it should meet the following
> conditions:
> ||expression||Expect the result||
> |timestampadd(MINUTE, -1, time '00:00:00')|NULL|
> |timestampadd(MINUTE, 1, time '00:00:00')|00:01:00|
> |timestampadd(MINUTE, 1, time '23:59:59')|00:00:59|
> |timestampadd(SECOND, 1, time '23:59:59')|00:00:00|
> |timestampadd(HOUR, 1, time '23:59:59')|00:59:59|
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2696) Filter containing IN clause not passed to Enumerable.scan
[
https://issues.apache.org/jira/browse/CALCITE-2696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16697096#comment-16697096
]
Dirk Mahler commented on CALCITE-2696:
--
Yes, it's the default threshold. I've built the current 1.18.0-SNAPSHOT from
source and used Integer.MAX_VALUE and the "problem" disappeared. Is there a way
to make the setting configurabe (see setup in the description/attached test
case)?
> Filter containing IN clause not passed to Enumerable.scan
> -
>
> Key: CALCITE-2696
> URL: https://issues.apache.org/jira/browse/CALCITE-2696
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Dirk Mahler
>Assignee: Julian Hyde
>Priority: Major
> Attachments: calcite-in-clause.zip
>
>
> I'm using the Calcite JDBC driver with an own SchemaFactory (defined by a
> model property) that provides a schema containing a
> ProjectableFilterableTable:
> {code:java}
> String model = "inline:" //
> + "{" //
> + " version: '1.0', " //
> + " defaultSchema: 'test'," //
> + " schemas: [" //
> + " {" //
> + " name: 'test'," //
> + " type: 'custom'," //
> + " factory: '" + TestSchemaFactory.class.getName() + "'" //
> + " }"
> + " ]" //
> + "}";
> Properties properties = new Properties();
> properties.put(CalciteConnectionProperty.MODEL.camelName(), model);
> connection = DriverManager.getConnection("jdbc:calcite:", properties);
> {code}
>
>
> {code:java}
> class TestTable extends AbstractQueryableTable implements
> ProjectableFilterableTable {
> public Enumerable scan(DataContext root, List filters,
> int[] projects) {
> ...
> }
> ...
> }{code}
>
> It maps to a Java class and provides two Integer typed columns "value1" and
> "value2".
> The following query leads to a quite expensive behavior in the scan method if
> the following statement is executed:
>
> {code:java}
> SELECT "value" FROM "TEST_TABLE" WHERE "value1" = 1 AND "value2" in
> (1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20)
> {code}
> The scan method is invoked with a filter that only covers the part "value1" =
> 1, the IN clause is completely omitted. The result on the JDBC side is still
> valid but in my case this still leads to a full scan of a large underlying
> data set (millions of rows).
> Interestingly the filter part reflecting the IN operator is provided if the
> number of elements in the list is below 20. It seems that this is controlled
> by
> org.apache.calcite.sql2rel.SqlToRelConverter.Config#getInSubQueryThreshold.
> It would at be very helpful if this behavior could be confgiured on the JDBC
> property level.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2696) Filter containing IN clause not passed to Enumerable.scan
[
https://issues.apache.org/jira/browse/CALCITE-2696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16697096#comment-16697096
]
Dirk Mahler edited comment on CALCITE-2696 at 11/23/18 12:54 PM:
-
Yes, it's the default threshold. I've built the current 1.18.0-SNAPSHOT from
source and used Integer.MAX_VALUE and the "problem" disappeared. Is there a way
to make the setting configurable (see setup in the description/attached test
case)?
was (Author: dirk.mahler):
Yes, it's the default threshold. I've built the current 1.18.0-SNAPSHOT from
source and used Integer.MAX_VALUE and the "problem" disappeared. Is there a way
to make the setting configurabe (see setup in the description/attached test
case)?
> Filter containing IN clause not passed to Enumerable.scan
> -
>
> Key: CALCITE-2696
> URL: https://issues.apache.org/jira/browse/CALCITE-2696
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Dirk Mahler
>Assignee: Julian Hyde
>Priority: Major
> Attachments: calcite-in-clause.zip
>
>
> I'm using the Calcite JDBC driver with an own SchemaFactory (defined by a
> model property) that provides a schema containing a
> ProjectableFilterableTable:
> {code:java}
> String model = "inline:" //
> + "{" //
> + " version: '1.0', " //
> + " defaultSchema: 'test'," //
> + " schemas: [" //
> + " {" //
> + " name: 'test'," //
> + " type: 'custom'," //
> + " factory: '" + TestSchemaFactory.class.getName() + "'" //
> + " }"
> + " ]" //
> + "}";
> Properties properties = new Properties();
> properties.put(CalciteConnectionProperty.MODEL.camelName(), model);
> connection = DriverManager.getConnection("jdbc:calcite:", properties);
> {code}
>
>
> {code:java}
> class TestTable extends AbstractQueryableTable implements
> ProjectableFilterableTable {
> public Enumerable scan(DataContext root, List filters,
> int[] projects) {
> ...
> }
> ...
> }{code}
>
> It maps to a Java class and provides two Integer typed columns "value1" and
> "value2".
> The following query leads to a quite expensive behavior in the scan method if
> the following statement is executed:
>
> {code:java}
> SELECT "value" FROM "TEST_TABLE" WHERE "value1" = 1 AND "value2" in
> (1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20)
> {code}
> The scan method is invoked with a filter that only covers the part "value1" =
> 1, the IN clause is completely omitted. The result on the JDBC side is still
> valid but in my case this still leads to a full scan of a large underlying
> data set (millions of rows).
> Interestingly the filter part reflecting the IN operator is provided if the
> number of elements in the list is below 20. It seems that this is controlled
> by
> org.apache.calcite.sql2rel.SqlToRelConverter.Config#getInSubQueryThreshold.
> It would at be very helpful if this behavior could be confgiured on the JDBC
> property level.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2701) Make generated Baz classes immutable
Stamatis Zampetakis created CALCITE-2701:
Summary: Make generated Baz classes immutable
Key: CALCITE-2701
URL: https://issues.apache.org/jira/browse/CALCITE-2701
Project: Calcite
Issue Type: Improvement
Components: core
Affects Versions: 1.17.0
Reporter: Stamatis Zampetakis
Assignee: Julian Hyde
Fix For: 1.18.0
Currently the Baz classes that are used to execute queries in the
EnumerableConvention are stateful since the code generated by
EnumerableRelImplementor#implementRoot method creates an instance variable
(i.e., DataContext root). Every call to the bind method changes the value of
the root variable making the object mutable.
I propose to remove the instance variable and in the body of the method use the
DataContext passed as a parameter.
It appears that the addition of the instance variable was a workaround for a
bug in Janino (JANINO-169). It seems that the bug is no longer present at the
current version of Janino used in Calcite (3.0.9) since the test
JdbcTest#testJanino169 (and the complete suite) pass successfully with the
proposed modification.
Unfortunately, I couldn't verify the fix in the release notes of Janino neither
in the commit history. The best, I could find is the following commits in the
Janino repository:
{code:none}
commit fe5edc1904278c1c189f3379e06417aaf4a26315
Author: aunkrig
Date: Wed Jan 22 21:19:48 2014 +
Partly fixed JANINO-169 - now you get "Compiler limitation: Initializers cannot
access local variables declared in an enclosing block".
commit 4d2bacf16229ac1278eafa0fb4d5a0377134d3f2
Author: aunkrig
Date: Wed Jan 22 15:03:17 2014 +
Added test case for JANINO-169.
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2699) The bug of timestampadd handles time
[
https://issues.apache.org/jira/browse/CALCITE-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16696656#comment-16696656
]
Zoltan Haindrich commented on CALCITE-2699:
---
I've just checked {{10.1.26-MariaDB-0+deb9u1}}
{code}
> select timestampadd(MINUTE, -1, time '00:00:00');
-00:01:00
1 row in set (0.00 sec)
{code}
so I think even mysql don't return null in this case...sorry I don't
follow...why would it make sense?
> The bug of timestampadd handles time
> -
>
> Key: CALCITE-2699
> URL: https://issues.apache.org/jira/browse/CALCITE-2699
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0, 1.18.0
>Reporter: xuqianjin
>Assignee: Julian Hyde
>Priority: Major
>
> Two errors occur when {{timestampadd(MINUTE, 1, time '01:00:00')}} is
> executed:
> # The return result can only be of {{TimeStamp}} type and is expected to be
> of {{Time}} type
> # The return value is {{1970-01-01 01:01:00}}, and the expectation is
> {{01:01:00}}
> # Compared with {{mysql}} database, I think it should meet the following
> conditions:
> ||expression||Expect the result||
> |timestampadd(MINUTE, -1, time '00:00:00')|NULL|
> |timestampadd(MINUTE, 1, time '00:00:00')|00:01:00|
> |timestampadd(MINUTE, 1, time '23:59:59')|00:00:59|
> |timestampadd(SECOND, 1, time '23:59:59')|00:00:00|
> |timestampadd(HOUR, 1, time '23:59:59')|00:59:59|
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2699) The bug of timestampadd handles time
[
https://issues.apache.org/jira/browse/CALCITE-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16696602#comment-16696602
]
xuqianjin commented on CALCITE-2699:
[~kgyrtkirk] Yes, that's right. I think it makes sense to return null
> The bug of timestampadd handles time
> -
>
> Key: CALCITE-2699
> URL: https://issues.apache.org/jira/browse/CALCITE-2699
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0, 1.18.0
>Reporter: xuqianjin
>Assignee: Julian Hyde
>Priority: Major
>
> Two errors occur when {{timestampadd(MINUTE, 1, time '01:00:00')}} is
> executed:
> # The return result can only be of {{TimeStamp}} type and is expected to be
> of {{Time}} type
> # The return value is {{1970-01-01 01:01:00}}, and the expectation is
> {{01:01:00}}
> # Compared with {{mysql}} database, I think it should meet the following
> conditions:
> ||expression||Expect the result||
> |timestampadd(MINUTE, -1, time '00:00:00')|NULL|
> |timestampadd(MINUTE, 1, time '00:00:00')|00:01:00|
> |timestampadd(MINUTE, 1, time '23:59:59')|00:00:59|
> |timestampadd(SECOND, 1, time '23:59:59')|00:00:00|
> |timestampadd(HOUR, 1, time '23:59:59')|00:59:59|
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2699) The bug of timestampadd handles time
[
https://issues.apache.org/jira/browse/CALCITE-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16696588#comment-16696588
]
Zoltan Haindrich commented on CALCITE-2699:
---
I think for {{timestampadd(MINUTE, -1, time '00:00:00')}}: NULL would be an
unexpected result
> The bug of timestampadd handles time
> -
>
> Key: CALCITE-2699
> URL: https://issues.apache.org/jira/browse/CALCITE-2699
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0, 1.18.0
>Reporter: xuqianjin
>Assignee: Julian Hyde
>Priority: Major
>
> Two errors occur when {{timestampadd(MINUTE, 1, time '01:00:00')}} is
> executed:
> # The return result can only be of {{TimeStamp}} type and is expected to be
> of {{Time}} type
> # The return value is {{1970-01-01 01:01:00}}, and the expectation is
> {{01:01:00}}
> # Compared with {{mysql}} database, I think it should meet the following
> conditions:
> ||expression||Expect the result||
> |timestampadd(MINUTE, -1, time '00:00:00')|NULL|
> |timestampadd(MINUTE, 1, time '00:00:00')|00:01:00|
> |timestampadd(MINUTE, 1, time '23:59:59')|00:00:59|
> |timestampadd(SECOND, 1, time '23:59:59')|00:00:00|
> |timestampadd(HOUR, 1, time '23:59:59')|00:59:59|
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
