[jira] [Resolved] (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 resolved CALCITE-2699.
Resolution: Fixed
> 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
> Fix For: 1.18.0, 1.17.0
>
>
> 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|
> |timestampadd(DAY, -1, time '23:59:59')|23:59:59|
> |timestampadd(WEEK, -1, time '23:59:59')|23:59:59|
> |timestampadd(MONTH, -1, time '23:59:59')|23:59:59|
> |timestampadd(QUARTER, -1, time '23:59:59')|23:59:59|
> |timestampadd(YEAR, -1, time '23:59:59')|23: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
Fix Version/s: 1.17.0
1.18.0
> 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
> Fix For: 1.17.0, 1.18.0
>
>
> 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|
> |timestampadd(DAY, -1, time '23:59:59')|23:59:59|
> |timestampadd(WEEK, -1, time '23:59:59')|23:59:59|
> |timestampadd(MONTH, -1, time '23:59:59')|23:59:59|
> |timestampadd(QUARTER, -1, time '23:59:59')|23:59:59|
> |timestampadd(YEAR, -1, time '23:59:59')|23:59:59|
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2637) Prefix minus operator failed in between and clause
[
https://issues.apache.org/jira/browse/CALCITE-2637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16706060#comment-16706060
]
yuqi commented on CALCITE-2637:
---
Fixed
> Prefix minus operator failed in between and clause
> --
>
> Key: CALCITE-2637
> URL: https://issues.apache.org/jira/browse/CALCITE-2637
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: yuqi
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.18.0
>
>
> We can reproduce it like this
> {code:java}
> public static void main(String[] args) {
> try {
> SchemaPlus rootSchema =
> Frameworks.createRootSchema(true);
> rootSchema.add("TABLE_RESULT", new AbstractTable() {
> public RelDataType getRowType(final
> RelDataTypeFactory typeFactory) {
> RelDataTypeFactory.FieldInfoBuilder
> builder = typeFactory.builder();
> RelDataType t1 =
> typeFactory.createTypeWithNullability(typeFactory.createSqlType(SqlTypeName.INTEGER),
> true);
> RelDataType t2 =
> typeFactory.createTypeWithNullability(typeFactory.createSqlType(SqlTypeName.CHAR),
> true);
> RelDataType t3 =
> typeFactory.createTypeWithNullability(typeFactory.createSqlType(SqlTypeName.INTEGER),
> true);
> builder.add("ID", t1);
> builder.add("NAME", t2);
> builder.add("SCORE", t3);;
> return builder.build();
> }
> });
> final FrameworkConfig config =
> Frameworks.newConfigBuilder()
> .parserConfig(SqlParser.Config.DEFAULT)
> .defaultSchema(rootSchema)
> .build();
> Planner planner = Frameworks.getPlanner(config);
> String sql = "select id, score between - score * 5 and
> 100 from table_result";
> SqlNode parse = planner.parse(sql);
> SqlNode validate = planner.validate(parse);
> RelRoot root = planner.rel(validate);
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> {code}
> the above code will cause the following problem:
> {code:java}
> org.apache.calcite.sql.parser.SqlParseException: Encountered "- score" at
> line 1, column 26.
> Was expecting one of:
> "SYMMETRIC" ...
> "ASYMMETRIC" ...
> "+" ...
> "-" ...
> "-" ...
> "-" ...
> "-" ...
> ...
> ...
> ...
> ...
> ...
> ...
> ...
> "TRUE" ...
> "FALSE" ...
> "UNKNOWN" ...
> "NULL" ...
> ...
> ...
> ...
> "DATE" ...
> "TIME" ...
> "TIMESTAMP" ...
> "INTERVAL" ...
> "?" ...
> "CAST" ...
> "EXTRACT" ...
> "POSITION" ...
> "CONVERT" ...
> "TRANSLATE" ...
> "OVERLAY" ...
> "FLOOR" ...
> "CEIL" ...
> "CEILING" ...
> "SUBSTRING" ...
> "TRIM" ...
> "CLASSIFIER" ...
> "MATCH_NUMBER" ...
> "RUNNING" ...
> "PREV" ...
> "NEXT" ...
> ...
> "MULTISET" ...
> "ARRAY" ...
> "PERIOD" ...
> "SPECIFIC" ...
> ...
> ...
> ...
> ...
> ...
> "ABS" ...
> "AVG" ...
> "CARDINALITY" ...
> "CHAR_LENGTH" ...
> "CHARACTER_LENGTH" ...
> "COALESCE" ...
> "COLLECT" ...
> "COVAR_POP" ...
> "COVAR_SAMP" ...
> {code}
--
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=16706052#comment-16706052
]
Julian Hyde commented on CALCITE-2703:
--
{quote}I opened this JIRA case because I believe a cache will be beneficial for
the majority of users.{quote}
I don't believe it will be beneficial to a majority (taking into account the
hidden cost of extra complexity). However, I believe it could be beneficial for
some users with particular work-loads. I think it is the kind of feature that
should be enabled using a runtime property, disabled by default. Could you do
that, and without significantly increasing the complexity of the default code
path? I will accept this PR if you can do that.
> 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=16705864#comment-16705864
]
Stamatis Zampetakis commented on CALCITE-2703:
--
The first reason to skip dynamic functions is the restriction imposed by the
Javadoc shown below:
{code:java}
/**
* @return true iff it is unsafe to cache query plans referencing this
* operator; false is assumed by default
*/
public boolean isDynamicFunction() {
return false;
}
{code}
but the real reason is that some dynamic functions (e.g., RAND etc) have the
@Determinstic annotation which ends up creating static fields in generated
classes and this do not work well with the cache. Maybe we should re-consider
which functions we mark as determinstic.
{quote}
What do you mean by "server" here?
{quote}
I meant through the connection interface. Typically, connection indicates
connection to a server so that's how server came into the discussion. I know
that you don't have to start a server, sorry for the confusion.
> 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-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=16705819#comment-16705819
]
Vladimir Sitnikov edited comment on CALCITE-2703 at 12/1/18 1:20 PM:
-
[~zabetak], what is the reason to skip class cache in case the plan contains
dynamic functions?
Apparently PR#950 adds a cache in front of {{Janino#compile(String): Class}},
and the cache is better be placed right into {{getBindable}} method to cover
all its uses.
was (Author: vladimirsitnikov):
[~zabetak], what is the reason to skip class cache in case the plan contains
dynamic functions?
> 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=16705823#comment-16705823
]
Vladimir Sitnikov commented on CALCITE-2703:
{quote}Calcite as a server.{quote}
I don't get what do you mean by "server" here.
One can access in-process Calcite via {{DriverManager.getConnection}}. You
don't have to "start server" for that.
> 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=16705819#comment-16705819 ] Vladimir Sitnikov commented on CALCITE-2703: [~zabetak], what is the reason to skip class cache in case the plan contains dynamic functions? > 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-2662) Planner: allow parsing directly a stream instead of a java.lang.String
[ https://issues.apache.org/jira/browse/CALCITE-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16705766#comment-16705766 ] Enrico Olivelli commented on CALCITE-2662: -- [~julianhyde] patch is ready from my side. (sorry for double posting, I don't want which is the best place to comment Jira vs github) > Planner: allow parsing directly a stream instead of a java.lang.String > -- > > Key: CALCITE-2662 > URL: https://issues.apache.org/jira/browse/CALCITE-2662 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.17.0 >Reporter: Enrico Olivelli >Assignee: Julian Hyde >Priority: Major > > In 1.17.0 the org.apache.calcite.tools.Planner interface only accept a > java.lang.String as input. > In order to reduce memory allocations and copies it will be useful that the > planner could accept the query in a more 'raw' format. > Creating a java.lang.String is very expensive, and if your "query" is coming > from the network (think about a Netty Direct memory ByteBuf) you are forced > to create a copy of the text of the query. -- 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=16705762#comment-16705762 ] Stamatis Zampetakis commented on CALCITE-2703: -- That's right! I am using many parts of it but not Calcite as a server. > 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-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=16705762#comment-16705762 ] Stamatis Zampetakis edited comment on CALCITE-2703 at 12/1/18 10:02 AM: That's right! I am using many independent parts of it (e.g., RelNodes, Optimizer, etc) but not Calcite as a server. was (Author: zabetak): That's right! I am using many parts of it but not Calcite as a server. > 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=16705750#comment-16705750
]
Vladimir Sitnikov commented on CALCITE-2703:
{quote} thus does not pass from the PreparedStatement{quote}
Do you mean you are not using PreparedStatement to access Calcite?
> 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=16705738#comment-16705738
]
Stamatis Zampetakis commented on CALCITE-2703:
--
{quote}
In other words, what if we add a caching layer in-between PreparedStatement and
EnumerableInterpretable#toBindable?
{quote}
[~vladimirsitnikov] That was kind of my original idea but the problem with this
is that whoever does not use Calcite as a server (e.g., me) thus does not pass
from the PreparedStatement. This mean, that if he uses the EnumerableConvention
he will potentially need to add another cache at the application layer.
[~julianhyde] I opened this JIRA case because I believe a cache will be
beneficial for the majority of users. If you believe it is not the case, I will
close this issue and we will add the cache outside of Calcite. Other than that
using Calcite's interpreter is not an alternative since it also passes from
Janino thus it suffers from the same compilation/ class loading overhead.
> 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)
