[jira] [Commented] (CALCITE-2704) Multilingual decoded problem
[
https://issues.apache.org/jira/browse/CALCITE-2704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16698596#comment-16698596
]
ASF GitHub Bot commented on CALCITE-2704:
-
Github user F21 commented on the issue:
https://github.com/apache/calcite-avatica/pull/76
@2k124 Thanks for opening the JIRA case. Can you also add a test for this?
> Multilingual decoded problem
>
>
> Key: CALCITE-2704
> URL: https://issues.apache.org/jira/browse/CALCITE-2704
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.11.0, avatica-1.12.0
>Reporter: pufan
>Priority: Blocker
>
> When we execute SQL with Chinese characters, we find that the server parses
> it in gibberish.
> After checking the code, we found that:
> org.apache.calcite.avatica.server.AvaticaJsonHandler.java line 109：
> {code:java}
> //The readFully method USES utf-8 encoding internally.
> rawRequest = AvaticaUtils.readFully(inputStream, buffer);
> {code}
> But in the org.apache.calcite.avatica.server.AvaticaJsonHandler.java line 116：
> {code:java}
> // Decoded using iso-8859-1 Cause Chinese garble.
> final String jsonRequest = new String(rawRequest.getBytes("ISO-8859-1"),
> "UTF-8");
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2701) Ensure that the "Baz" classes generated by Janino are thread-safe
[
https://issues.apache.org/jira/browse/CALCITE-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16699789#comment-16699789
]
Julian Hyde commented on CALCITE-2701:
--
I changed the subject to mention "thread-safe" rather than "immutable", since
the real goal is to be able to share classes (instances?) among clients.
> Ensure that the "Baz" classes generated by Janino are thread-safe
> -
>
> 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
>Priority: Major
> Labels: pull-request-available
> 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] [Updated] (CALCITE-2701) Ensure that the "Baz" classes generated by Janino are thread-safe
[
https://issues.apache.org/jira/browse/CALCITE-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-2701:
-
Summary: Ensure that the "Baz" classes generated by Janino are thread-safe
(was: Make instances of generated Baz classes immutable)
> Ensure that the "Baz" classes generated by Janino are thread-safe
> -
>
> 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
>Priority: Major
> Labels: pull-request-available
> 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] [Updated] (CALCITE-2711) Upgrade SQLLine to 1.6.0
[
https://issues.apache.org/jira/browse/CALCITE-2711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-2711:
-
Description:
Upgrade SQLLine to 1.6.0.
SQLLine is a big improvement over 1.5.0; it uses jline3, and therefore provides
color highlighting, line continuation, and multi-line editing. See [the release
notes|https://github.com/julianhyde/sqlline/blob/master/HISTORY.md#160-2018-11-26].
>From the release notes:
{quote}
*WARNING*: Between version 2 and 3, jline changed the format of its history
file. After this change, you may need to remove your history file
({{~/.sqlline/history}}) or provide a {{--historyfile}} argument before SQLLine
will start successfully.
{quote}
was:
Upgrade SQLLine to 1.6.0.
SQLLine is a big improvement over 1.5.0; it uses jline3, and therefore provides
color highlighting, line continuation, and multi-line editing. See [the release
notes|https://github.com/julianhyde/sqlline/blob/master/HISTORY.md#160-2018-11-26].
> Upgrade SQLLine to 1.6.0
>
>
> Key: CALCITE-2711
> URL: https://issues.apache.org/jira/browse/CALCITE-2711
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> Upgrade SQLLine to 1.6.0.
> SQLLine is a big improvement over 1.5.0; it uses jline3, and therefore
> provides color highlighting, line continuation, and multi-line editing. See
> [the release
> notes|https://github.com/julianhyde/sqlline/blob/master/HISTORY.md#160-2018-11-26].
> From the release notes:
> {quote}
> *WARNING*: Between version 2 and 3, jline changed the format of its history
> file. After this change, you may need to remove your history file
> ({{~/.sqlline/history}}) or provide a {{--historyfile}} argument before
> SQLLine will start successfully.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2711) Upgrade SQLLine to 1.6.0
Julian Hyde created CALCITE-2711: Summary: Upgrade SQLLine to 1.6.0 Key: CALCITE-2711 URL: https://issues.apache.org/jira/browse/CALCITE-2711 Project: Calcite Issue Type: Bug Reporter: Julian Hyde Assignee: Julian Hyde Upgrade SQLLine to 1.6.0. SQLLine is a big improvement over 1.5.0; it uses jline3, and therefore provides color highlighting, line continuation, and multi-line editing. See [the release notes|https://github.com/julianhyde/sqlline/blob/master/HISTORY.md#160-2018-11-26]. -- 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|
|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|
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}}
# 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|
> |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-2701) Ensure that the "Baz" classes generated by Janino are thread-safe
[
https://issues.apache.org/jira/browse/CALCITE-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16700020#comment-16700020
]
Stamatis Zampetakis commented on CALCITE-2701:
--
The main goal is to re-use instances and avoid memory-leaks due to the
DataContext (and information stored in it). Of course, thread-safety is another
important and desired benefit of immutability.
> Ensure that the "Baz" classes generated by Janino are thread-safe
> -
>
> 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
>Priority: Major
> Labels: pull-request-available
> 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-2705) Duplicated selectivity in metadata list
[ https://issues.apache.org/jira/browse/CALCITE-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16698858#comment-16698858 ] Lantao Jin commented on CALCITE-2705: - https://github.com/apache/calcite/pull/940 [~julianhyde] could you please take a look at it? Thanks. > Duplicated selectivity in metadata list > --- > > Key: CALCITE-2705 > URL: https://issues.apache.org/jira/browse/CALCITE-2705 > Project: Calcite > Issue Type: Bug >Reporter: Lantao Jin >Assignee: Julian Hyde >Priority: Trivial > > Duplicated selectivity in metadata list in web site -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CALCITE-2706) Do not make IN conversion
[ https://issues.apache.org/jira/browse/CALCITE-2706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mykola Zerniuk closed CALCITE-2706. --- Resolution: Duplicate > Do not make IN conversion > - > > Key: CALCITE-2706 > URL: https://issues.apache.org/jira/browse/CALCITE-2706 > Project: Calcite > Issue Type: Bug >Reporter: Mykola Zerniuk >Assignee: Julian Hyde >Priority: Major > > We current have only two options with IN operator handling - replace it with > ORs or sub-queries depending on the inSubQueryThreshold. Add third option to > prevent any conversions and leave IN `as is`. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2705) Duplicated selectivity in metadata list
[ https://issues.apache.org/jira/browse/CALCITE-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lantao Jin updated CALCITE-2705: Summary: Duplicated selectivity in metadata list (was: Duplicated selectivity in metastore list) > Duplicated selectivity in metadata list > --- > > Key: CALCITE-2705 > URL: https://issues.apache.org/jira/browse/CALCITE-2705 > Project: Calcite > Issue Type: Bug >Reporter: Lantao Jin >Assignee: Julian Hyde >Priority: Trivial > > Duplicated selectivity in metastore list in web site -- 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=16698911#comment-16698911
]
pengzhiwei commented on CALCITE-2696:
-
I think we should provide a config for user to keep "In" as it is. The problem
in this issue will be solved and also we can have a better performance than set
IN_SUB_QUERY_THRESHOLD to "Integer.MAX_VALUE".
> 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] [Commented] (CALCITE-2706) Do not make IN conversion
[ https://issues.apache.org/jira/browse/CALCITE-2706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16699058#comment-16699058 ] Stamatis Zampetakis commented on CALCITE-2706: -- No worries, can you please close this issue then? > Do not make IN conversion > - > > Key: CALCITE-2706 > URL: https://issues.apache.org/jira/browse/CALCITE-2706 > Project: Calcite > Issue Type: Bug >Reporter: Mykola Zerniuk >Assignee: Julian Hyde >Priority: Major > > We current have only two options with IN operator handling - replace it with > ORs or sub-queries depending on the inSubQueryThreshold. Add third option to > prevent any conversions and leave IN `as is`. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2705) Duplicated selectivity in metadata list
[ https://issues.apache.org/jira/browse/CALCITE-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lantao Jin updated CALCITE-2705: Description: Duplicated selectivity in metadata list in web site (was: Duplicated selectivity in metastore list in web site) > Duplicated selectivity in metadata list > --- > > Key: CALCITE-2705 > URL: https://issues.apache.org/jira/browse/CALCITE-2705 > Project: Calcite > Issue Type: Bug >Reporter: Lantao Jin >Assignee: Julian Hyde >Priority: Trivial > > Duplicated selectivity in metadata list in web site -- 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=16698976#comment-16698976
]
Stamatis Zampetakis commented on CALCITE-2696:
--
Hi [~pzw2018], I suppose your suggestion implies that CALCITE-2630 is
resolved.
> 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] [Commented] (CALCITE-2632) Add hashCode and equals implementations to RexNode
[
https://issues.apache.org/jira/browse/CALCITE-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16699068#comment-16699068
]
Zoltan Haindrich commented on CALCITE-2632:
---
I was looking into how to fix an issue; and I've just [noticed this issue
again|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rex/RexSimplify.java#L670]...
I think this more important...than it looks like...
> Add hashCode and equals implementations to RexNode
> ---
>
> Key: CALCITE-2632
> URL: https://issues.apache.org/jira/browse/CALCITE-2632
> Project: Calcite
> Issue Type: Bug
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Major
>
> Right now RexNode doesn't have any equals or hashCode functions; which makes
> it rely on the default implementation.
> But when we are writing simplification logics we sometimes forget to use
> {{toString()}} during comparisions and may try to rely on pure equals:
> * there is a [Set of
> RexNode-s|https://github.com/apache/calcite/blob/5b16e23dff03e5eaed80642ae91e28ebf806e6b0/core/src/main/java/org/apache/calcite/rex/RexSimplify.java#L1104]
> during {{AND}} simplification and in [RexUtil as
> well|https://github.com/apache/calcite/blob/5b16e23dff03e5eaed80642ae91e28ebf806e6b0/core/src/main/java/org/apache/calcite/rex/RexUtil.java#L321]
> * I've by mistake just written rexNode.equals(otherRexNode) during the
> implementation of CALCITE-1413
> * I've just bumped into the same thing...that
> [RexUtil.andNot|https://github.com/apache/calcite/blob/5b16e23dff03e5eaed80642ae91e28ebf806e6b0/core/src/main/java/org/apache/calcite/rex/RexUtil.java#L1888]
> is also rely on itand I think those comparisions go back a while
> (~3years at least) ; and a bug is not appeared from it because this
> comparision is in most cases false.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2706) Do not make IN conversion
[ https://issues.apache.org/jira/browse/CALCITE-2706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16699036#comment-16699036 ] Mykola Zerniuk commented on CALCITE-2706: - Yes, sorry. Let's to continue discussion there. > Do not make IN conversion > - > > Key: CALCITE-2706 > URL: https://issues.apache.org/jira/browse/CALCITE-2706 > Project: Calcite > Issue Type: Bug >Reporter: Mykola Zerniuk >Assignee: Julian Hyde >Priority: Major > > We current have only two options with IN operator handling - replace it with > ORs or sub-queries depending on the inSubQueryThreshold. Add third option to > prevent any conversions and leave IN `as is`. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2705) Duplicated selectivity in metastore list
[ https://issues.apache.org/jira/browse/CALCITE-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lantao Jin updated CALCITE-2705: Description: Duplicated selectivity in metastore list in web site (was: Duplicated metastore list in web site) > Duplicated selectivity in metastore list > > > Key: CALCITE-2705 > URL: https://issues.apache.org/jira/browse/CALCITE-2705 > Project: Calcite > Issue Type: Bug >Reporter: Lantao Jin >Assignee: Julian Hyde >Priority: Trivial > > Duplicated selectivity in metastore list in web site -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2706) Do not make IN conversion
Mykola created CALCITE-2706: --- Summary: Do not make IN conversion Key: CALCITE-2706 URL: https://issues.apache.org/jira/browse/CALCITE-2706 Project: Calcite Issue Type: Bug Reporter: Mykola Assignee: Julian Hyde We current have only two options with IN operator handling - replace it with ORs or sub-queries depending on the inSubQueryThreshold. Add third option to prevent any conversions and leave IN `as is`. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2706) Do not make IN conversion
[ https://issues.apache.org/jira/browse/CALCITE-2706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16698957#comment-16698957 ] Stamatis Zampetakis commented on CALCITE-2706: -- It seems that this issue is more or less a duplicate of CALCITE-2630 isn't it? > Do not make IN conversion > - > > Key: CALCITE-2706 > URL: https://issues.apache.org/jira/browse/CALCITE-2706 > Project: Calcite > Issue Type: Bug >Reporter: Mykola Zerniuk >Assignee: Julian Hyde >Priority: Major > > We current have only two options with IN operator handling - replace it with > ORs or sub-queries depending on the inSubQueryThreshold. Add third option to > prevent any conversions and leave IN `as is`. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2708) UDAGs are not verified for single pattern variable in MATCH_RECOGNIZE
Dawid Wysakowicz created CALCITE-2708:
-
Summary: UDAGs are not verified for single pattern variable in
MATCH_RECOGNIZE
Key: CALCITE-2708
URL: https://issues.apache.org/jira/browse/CALCITE-2708
Project: Calcite
Issue Type: Bug
Reporter: Dawid Wysakowicz
Assignee: Julian Hyde
Query:
{code}
SELECT *
FROM Ticker
MATCH_RECOGNIZE (
ORDER BY proctime
MEASURES
udagg(A.price + B.tax) AS taxedPrice
PATTERN (A B)
DEFINE
A AS A.symbol = 'a'
) AS T
{code}
should fail with ValidationException, because udagg is applied to different
pattern variables.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2708) UDAGs are not verified for single pattern variable in MATCH_RECOGNIZE
[
https://issues.apache.org/jira/browse/CALCITE-2708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16699487#comment-16699487
]
Julian Hyde commented on CALCITE-2708:
--
Sounds reasonable.
[~dawidwys], On a separate matter, I'm working on CALCITE-1935 again, which
duplicates the work you've done in Flink somewhat. (By the way, congratulations
on all the good work you've been doing there.) I don't think it's possible to
share code, but I do think it's possible to share test cases. Is there any
chance you contribute to
[match.iq|https://github.com/julianhyde/calcite/blob/1935-match-recognize/core/src/test/resources/sql/match.iq]?
Then we'll end up with a set of SQL tests and results (including answers we've
checked against Oracle) so we'd know that both Calcite's and Flink's
implementation are compliant?
> UDAGs are not verified for single pattern variable in MATCH_RECOGNIZE
> -
>
> Key: CALCITE-2708
> URL: https://issues.apache.org/jira/browse/CALCITE-2708
> Project: Calcite
> Issue Type: Bug
>Reporter: Dawid Wysakowicz
>Assignee: Julian Hyde
>Priority: Major
> Labels: match
>
> Query:
> {code}
> SELECT *
> FROM Ticker
> MATCH_RECOGNIZE (
> ORDER BY proctime
> MEASURES
> udagg(A.price + B.tax) AS taxedPrice
> PATTERN (A B)
> DEFINE
> A AS A.symbol = 'a'
> ) AS T
> {code}
> should fail with ValidationException, because udagg is applied to different
> pattern variables.
--
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=16699484#comment-16699484 ] Enrico Olivelli commented on CALCITE-2662: -- Great. I will add the test soon This is the PR https://github.com/apache/calcite/pull/906 > 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-1935) Reference implementation for MATCH_RECOGNIZE
[
https://issues.apache.org/jira/browse/CALCITE-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16699512#comment-16699512
]
Julian Hyde commented on CALCITE-1935:
--
Over Thanksgiving, I started working on {{MATCH_RECOGNIZE}} again. I wrote a
standalone class called {{Automaton}} that allows you to build patterns
(basically regular expressions, but sufficient for the {{PATTERN}} sub-clause
of {{MATCH_RECOGNIZE}}), and execute them in a unit test.
Would someone like to help me develop this? We have support for {{*}} (zero or
more repeats), {{+}} (1 or more repeats) and \{m,n\} (bounded repeats) but
need {{|}} (or) and several others. It should be fairly straightforward
test-driven development: add tests to
[AutomatonTest|https://github.com/julianhyde/calcite/blob/1935-match-recognize/core/src/test/java/org/apache/calcite/runtime/AutomatonTest.java],
then change {{Automaton}}, {{AutomatonBuilder}}, {{Pattern}} or {{Matcher}}
until they pass.
We also need lots of SQL tests. Could someone write queries against Oracle’s
“ticker” table and paste the queries and results into {{match.iq}}?
There is some trickier integration to make {{JdbcTest.testMatch}} work
end-to-end; I am working on that.
See [my dev
branch|https://github.com/julianhyde/calcite/tree/1935-match-recognize/].
I have cherry-picked commits from [Zhiqiang He’s
branch|https://github.com/Zhiqiang-He/calcite/tree/calcite-1935-MR-Implementation3]
into my branch, so this will be a joint effort when it is finished.
> Reference implementation for MATCH_RECOGNIZE
>
>
> Key: CALCITE-1935
> URL: https://issues.apache.org/jira/browse/CALCITE-1935
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Labels: match
>
> We now have comprehensive support for parsing and validating MATCH_RECOGNIZE
> queries (see CALCITE-1570 and sub-tasks) but we cannot execute them. I know
> the purpose of this work is to do CEP within Flink, but a reference
> implementation that works on non-streaming data would be valuable.
> I propose that we add a class EnumerableMatch that can generate Java code to
> evaluate MATCH_RECOGNIZE queries on Enumerable data. It does not need to be
> efficient. I don't mind if it (say) buffers all the data in memory and makes
> O(n ^ 3) passes over it. People can make it more efficient over time.
> When we have a reference implementation, people can start playing with this
> feature. And we can start building a corpus of data sets, queries, and their
> expected result. The Flink implementation will be able to test against those
> same queries, and should give the same results, even though Flink will be
> reading streaming data.
> Let's create {{match.iq}} with the following query based on
> https://oracle-base.com/articles/12c/pattern-matching-in-oracle-database-12cr1:
> {code}
> !set outputformat mysql
> !use match
> SELECT *
> FROM sales_history MATCH_RECOGNIZE (
> PARTITION BY product
> ORDER BY tstamp
> MEASURES STRT.tstamp AS start_tstamp,
>LAST(UP.tstamp) AS peak_tstamp,
>LAST(DOWN.tstamp) AS end_tstamp,
>MATCH_NUMBER() AS mno
> ONE ROW PER MATCH
> AFTER MATCH SKIP TO LAST DOWN
> PATTERN (STRT UP+ FLAT* DOWN+)
> DEFINE
>UP AS UP.units_sold > PREV(UP.units_sold),
>FLAT AS FLAT.units_sold = PREV(FLAT.units_sold),
>DOWN AS DOWN.units_sold < PREV(DOWN.units_sold)
>) MR
> ORDER BY MR.product, MR.start_tstamp;
> PRODUCTSTART_TSTAM PEAK_TSTAMP END_TSTAMP MNO
> -- --- --- --- --
> TWINKIES 01-OCT-2014 03-OCT-2014 06-OCT-2014 1
> TWINKIES 06-OCT-2014 08-OCT-2014 09-OCT-2014 2
> TWINKIES 09-OCT-2014 13-OCT-2014 16-OCT-2014 3
> TWINKIES 16-OCT-2014 18-OCT-2014 20-OCT-2014 4
> 4 rows selected.
> !ok
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2701) Make generated Baz classes immutable
[
https://issues.apache.org/jira/browse/CALCITE-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16699551#comment-16699551
]
Julian Hyde commented on CALCITE-2701:
--
FWIW, This commit seems to be removing the workaround for JANINO-169 that was
added in
[8e2f4ec3|https://github.com/apache/calcite/commit/8e2f4ec326074e799788f0d83bf9aa647ed30d93].
Do you have a link to the Janino issue? I could only find [the Janino commit
that introduced the test case for
it|https://github.com/janino-compiler/janino/commit/4d2bacf16229ac1278eafa0fb4d5a0377134d3f2].
> 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
>Priority: Major
> Labels: pull-request-available
> 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] [Created] (CALCITE-2705) Duplicated metastore list
Lantao Jin created CALCITE-2705: --- Summary: Duplicated metastore list Key: CALCITE-2705 URL: https://issues.apache.org/jira/browse/CALCITE-2705 Project: Calcite Issue Type: Bug Reporter: Lantao Jin Assignee: Julian Hyde Duplicated metastore list in web site -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2700) MaterializedView rewrite rules are matched on physical operators.
[
https://issues.apache.org/jira/browse/CALCITE-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-2700:
-
Description:
Today, all the MV related rewrite rules can be applied to both logical and
physical operators.
This will lead to many redundant matches and make the match process not
efficient.
One optimization we can do is just limit the rules application to logical
operators only.
{noformat}
2018-11-23 12:08:14,468 [main] INFO volcano.VolcanoRuleCall:193 - call#659:
Apply rule [MaterializedViewJoinRule(Project-Filter)] to
[rel#101:LogicalProject.NONE.[](input=rel#99:Subset#7.NONE.[],X=+($0,
1),name=$2),
rel#97:LogicalFilter.NONE.[](input=rel#44:Subset#0.ENUMERABLE.[],condition==(CAST($1):INTEGER
NOT NULL, 10))]
2018-11-23 12:08:14,468 [main] INFO volcano.VolcanoRuleCall:91 - Transform to:
rel#111 via MaterializedViewJoinRule(Project-Filter)
2018-11-23 12:08:14,468 [main] INFO volcano.VolcanoRuleCall:218 - call#659
generated 1 successors: [LogicalProject#111]
2018-11-23 12:08:14,484 [main] INFO volcano.VolcanoRuleCall:193 - call#738:
Apply rule [MaterializedViewJoinRule(Project-Filter)] to
[rel#103:EnumerableProject.ENUMERABLE.[](input=rel#102:Subset#7.ENUMERABLE.[],X=+($0,
1),name=$2),
rel#116:EnumerableFilter.ENUMERABLE.[](input=rel#44:Subset#0.ENUMERABLE.[],condition==(CAST($1):INTEGER
NOT NULL, 10))]
2018-11-23 12:08:14,484 [main] INFO volcano.VolcanoRuleCall:91 - Transform to:
rel#118 via MaterializedViewJoinRule(Project-Filter)
2018-11-23 12:08:14,484 [main] INFO volcano.VolcanoRuleCall:218 - call#738
generated 1 successors: [LogicalProject#118]
2018-11-23 12:08:14,499 [main] INFO volcano.VolcanoRuleCall:193 - call#626:
Apply rule [MaterializedViewJoinRule(Project-Filter)] to
[rel#100:LogicalProject.NONE.[](input=rel#99:Subset#7.NONE.[],empid=$0,deptno=$1,name=$2),
rel#97:LogicalFilter.NONE.[](input=rel#44:Subset#0.ENUMERABLE.[],condition==(CAST($1):INTEGER
NOT NULL, 10))]
2018-11-23 12:08:14,499 [main] INFO volcano.VolcanoRuleCall:91 - Transform to:
rel#127 via MaterializedViewJoinRule(Project-Filter)
2018-11-23 12:08:14,499 [main] INFO volcano.VolcanoRuleCall:218 - call#626
generated 1 successors: [LogicalProject#127]
2018-11-23 12:08:14,515 [main] INFO volcano.VolcanoRuleCall:193 - call#216:
Apply rule [MaterializedViewJoinRule(Filter)] to
[rel#47:LogicalFilter.NONE.[](input=rel#46:Subset#1.NONE.[],condition==(CAST($1):INTEGER
NOT NULL, 10))]
2018-11-23 12:08:14,515 [main] INFO volcano.VolcanoRuleCall:91 - Transform to:
rel#134 via MaterializedViewJoinRule(Filter)
2018-11-23 12:08:14,515 [main] INFO volcano.VolcanoRuleCall:218 - call#216
generated 1 successors: [LogicalProject#134]
2018-11-23 12:08:14,533 [main] INFO volcano.VolcanoRuleCall:193 - call#908:
Apply rule [MaterializedViewJoinRule(Project-Filter)] to
[rel#138:LogicalProject.NONE.[](input=rel#102:Subset#7.ENUMERABLE.[],X=+($0,
1),name=$2),
rel#116:EnumerableFilter.ENUMERABLE.[](input=rel#44:Subset#0.ENUMERABLE.[],condition==(CAST($1):INTEGER
NOT NULL, 10))]
2018-11-23 12:08:14,534 [main] INFO volcano.VolcanoRuleCall:91 - Transform to:
rel#141 via MaterializedViewJoinRule(Project-Filter)
2018-11-23 12:08:14,534 [main] INFO volcano.VolcanoRuleCall:218 - call#908
generated 1 successors: [LogicalProject#141]
2018-11-23 12:08:14,535 [main] INFO volcano.VolcanoRuleCall:193 - call#878:
Apply rule [MaterializedViewJoinRule(Project-Filter)] to
[rel#137:EnumerableProject.ENUMERABLE.[](input=rel#102:Subset#7.ENUMERABLE.[],empid=$0,deptno=$1,name=$2),
rel#116:EnumerableFilter.ENUMERABLE.[](input=rel#44:Subset#0.ENUMERABLE.[],condition==(CAST($1):INTEGER
NOT NULL, 10))]
2018-11-23 12:08:14,537 [main] INFO volcano.VolcanoRuleCall:91 - Transform to:
rel#145 via MaterializedViewJoinRule(Project-Filter)
2018-11-23 12:08:14,537 [main] INFO volcano.VolcanoRuleCall:218 - call#878
generated 1 successors: [LogicalProject#145]
2018-11-23 12:08:14,541 [main] INFO volcano.VolcanoRuleCall:193 - call#960:
Apply rule [MaterializedViewJoinRule(Project-Filter)] to
[rel#81:EnumerableProject.ENUMERABLE.[](input=rel#80:Subset#2.ENUMERABLE.[],X=+($0,
1),name=$2),
rel#150:EnumerableFilter.ENUMERABLE.[](input=rel#149:Subset#1.ENUMERABLE.[],condition==(CAST($1):INTEGER
NOT NULL, 10))]
2018-11-23 12:08:14,542 [main] INFO volcano.VolcanoRuleCall:91 - Transform to:
rel#152 via MaterializedViewJoinRule(Project-Filter)
2018-11-23 12:08:14,543 [main] INFO volcano.VolcanoRuleCall:218 - call#960
generated 1 successors: [LogicalProject#152]
2018-11-23 12:08:14,544 [main] INFO volcano.VolcanoRuleCall:193 - call#966:
Apply rule [MaterializedViewJoinRule(Filter)] to
[rel#150:EnumerableFilter.ENUMERABLE.[](input=rel#149:Subset#1.ENUMERABLE.[],condition==(CAST($1):INTEGER
NOT NULL, 10))]
2018-11-23 12:08:14,546 [main] INFO volcano.VolcanoRuleCall:91 - Transform to:
rel#156 via MaterializedViewJoinRule(Filter)
[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=16699459#comment-16699459 ] Julian Hyde commented on CALCITE-2662: -- Can you attach a link to the PR? If the PR is non-invasive I wouldn't strongly object to it. It may or may not improve performance significantly, but I acknowledge it would be convenient if people could parse a Reader. Can you add a test that error locations (line/column) work correctly. I suspect that this functionality uses a materialized string behind the scenes. > 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] [Updated] (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:all-tabpanel ] Julian Hyde updated CALCITE-2662: - Description: 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. was: 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. > 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] [Assigned] (CALCITE-2700) MaterializedView rewrite rules are matched on physical operators.
[ https://issues.apache.org/jira/browse/CALCITE-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesus Camacho Rodriguez reassigned CALCITE-2700: Assignee: Jesus Camacho Rodriguez (was: Julian Hyde) > MaterializedView rewrite rules are matched on physical operators. > - > > Key: CALCITE-2700 > URL: https://issues.apache.org/jira/browse/CALCITE-2700 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.17.0 >Reporter: Ken Wang >Assignee: Jesus Camacho Rodriguez >Priority: Minor > > Today, all the MV related rewrite rules can be applied to both logical and > physical operators. > This will lead to many redundant matches and make the match process not > efficient. > One optimization we can do is just limit the rules application to logical > operators only. > > 2018-11-23 12:08:14,468 [main] INFO volcano.VolcanoRuleCall:193 - call#659: > Apply rule [MaterializedViewJoinRule(Project-Filter)] to > [rel#101:LogicalProject.NONE.[](input=rel#99:Subset#7.NONE.[],X=+($0, > 1),name=$2), > rel#97:LogicalFilter.NONE.[](input=rel#44:Subset#0.ENUMERABLE.[],condition==(CAST($1):INTEGER > NOT NULL, 10))] > 2018-11-23 12:08:14,468 [main] INFO volcano.VolcanoRuleCall:91 - Transform > to: rel#111 via MaterializedViewJoinRule(Project-Filter) > 2018-11-23 12:08:14,468 [main] INFO volcano.VolcanoRuleCall:218 - call#659 > generated 1 successors: [LogicalProject#111] > 2018-11-23 12:08:14,484 [main] INFO volcano.VolcanoRuleCall:193 - call#738: > Apply rule [MaterializedViewJoinRule(Project-Filter)] to > [rel#103:EnumerableProject.ENUMERABLE.[](input=rel#102:Subset#7.ENUMERABLE.[],X=+($0, > 1),name=$2), > rel#116:EnumerableFilter.ENUMERABLE.[](input=rel#44:Subset#0.ENUMERABLE.[],condition==(CAST($1):INTEGER > NOT NULL, 10))] > 2018-11-23 12:08:14,484 [main] INFO volcano.VolcanoRuleCall:91 - Transform > to: rel#118 via MaterializedViewJoinRule(Project-Filter) > 2018-11-23 12:08:14,484 [main] INFO volcano.VolcanoRuleCall:218 - call#738 > generated 1 successors: [LogicalProject#118] > 2018-11-23 12:08:14,499 [main] INFO volcano.VolcanoRuleCall:193 - call#626: > Apply rule [MaterializedViewJoinRule(Project-Filter)] to > [rel#100:LogicalProject.NONE.[](input=rel#99:Subset#7.NONE.[],empid=$0,deptno=$1,name=$2), > > rel#97:LogicalFilter.NONE.[](input=rel#44:Subset#0.ENUMERABLE.[],condition==(CAST($1):INTEGER > NOT NULL, 10))] > 2018-11-23 12:08:14,499 [main] INFO volcano.VolcanoRuleCall:91 - Transform > to: rel#127 via MaterializedViewJoinRule(Project-Filter) > 2018-11-23 12:08:14,499 [main] INFO volcano.VolcanoRuleCall:218 - call#626 > generated 1 successors: [LogicalProject#127] > 2018-11-23 12:08:14,515 [main] INFO volcano.VolcanoRuleCall:193 - call#216: > Apply rule [MaterializedViewJoinRule(Filter)] to > [rel#47:LogicalFilter.NONE.[](input=rel#46:Subset#1.NONE.[],condition==(CAST($1):INTEGER > NOT NULL, 10))] > 2018-11-23 12:08:14,515 [main] INFO volcano.VolcanoRuleCall:91 - Transform > to: rel#134 via MaterializedViewJoinRule(Filter) > 2018-11-23 12:08:14,515 [main] INFO volcano.VolcanoRuleCall:218 - call#216 > generated 1 successors: [LogicalProject#134] > 2018-11-23 12:08:14,533 [main] INFO volcano.VolcanoRuleCall:193 - call#908: > Apply rule [MaterializedViewJoinRule(Project-Filter)] to > [rel#138:LogicalProject.NONE.[](input=rel#102:Subset#7.ENUMERABLE.[],X=+($0, > 1),name=$2), > rel#116:EnumerableFilter.ENUMERABLE.[](input=rel#44:Subset#0.ENUMERABLE.[],condition==(CAST($1):INTEGER > NOT NULL, 10))] > 2018-11-23 12:08:14,534 [main] INFO volcano.VolcanoRuleCall:91 - Transform > to: rel#141 via MaterializedViewJoinRule(Project-Filter) > 2018-11-23 12:08:14,534 [main] INFO volcano.VolcanoRuleCall:218 - call#908 > generated 1 successors: [LogicalProject#141] > 2018-11-23 12:08:14,535 [main] INFO volcano.VolcanoRuleCall:193 - call#878: > Apply rule [MaterializedViewJoinRule(Project-Filter)] to > [rel#137:EnumerableProject.ENUMERABLE.[](input=rel#102:Subset#7.ENUMERABLE.[],empid=$0,deptno=$1,name=$2), > > rel#116:EnumerableFilter.ENUMERABLE.[](input=rel#44:Subset#0.ENUMERABLE.[],condition==(CAST($1):INTEGER > NOT NULL, 10))] > 2018-11-23 12:08:14,537 [main] INFO volcano.VolcanoRuleCall:91 - Transform > to: rel#145 via MaterializedViewJoinRule(Project-Filter) > 2018-11-23 12:08:14,537 [main] INFO volcano.VolcanoRuleCall:218 - call#878 > generated 1 successors: [LogicalProject#145] > 2018-11-23 12:08:14,541 [main] INFO volcano.VolcanoRuleCall:193 - call#960: > Apply rule [MaterializedViewJoinRule(Project-Filter)] to > [rel#81:EnumerableProject.ENUMERABLE.[](input=rel#80:Subset#2.ENUMERABLE.[],X=+($0, > 1),name=$2), >
[jira] [Comment Edited] (CALCITE-2671) GeodeFilter change to transform multiple OR s to use IN SET OQL predicate to significantly improve query performance
[ https://issues.apache.org/jira/browse/CALCITE-2671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686488#comment-16686488 ] Sandeep Chada edited comment on CALCITE-2671 at 11/26/18 5:38 PM: -- PR Link [https://github.com/apache/calcite/pull/942] was (Author: chadasa-gs): PR Link [https://github.com/apache/calcite/pull/938] > GeodeFilter change to transform multiple OR s to use IN SET OQL predicate to > significantly improve query performance > - > > Key: CALCITE-2671 > URL: https://issues.apache.org/jira/browse/CALCITE-2671 > Project: Calcite > Issue Type: Improvement > Components: geode >Reporter: Sandeep Chada >Assignee: Julian Hyde >Priority: Major > > In Geode when we are querying thousands of rows using an IN query, IN SET > query predicate gives high query performance than multiple OR s. > I am making the change in the GeodeFilter translateMatch function by first > checking if IN SET is applicable then only use it, otherwise the multiple OR > code is called. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2705) Duplicated selectivity in metadata list
[ https://issues.apache.org/jira/browse/CALCITE-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16698858#comment-16698858 ] Julian Hyde edited comment on CALCITE-2705 at 11/26/18 5:55 PM: https://github.com/apache/calcite/pull/940 was (Author: cltlfcjin): https://github.com/apache/calcite/pull/940 [~julianhyde] could you please take a look at it? Thanks. > Duplicated selectivity in metadata list > --- > > Key: CALCITE-2705 > URL: https://issues.apache.org/jira/browse/CALCITE-2705 > Project: Calcite > Issue Type: Bug >Reporter: Lantao Jin >Assignee: Julian Hyde >Priority: Trivial > > Duplicated selectivity in metadata list in web site -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (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:all-tabpanel
]
Julian Hyde closed CALCITE-2696.
Resolution: Not A Problem
I'm closing this, because behavior is as intended. There is a means to
configure the parameter. The issue of how to represent the IN expression if we
do not convert it to a Join is separate.
> 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] [Updated] (CALCITE-2708) In MATCH_RECOGNIZE, validator must ensure that arguments to a user-defined aggregate function come from a single pattern variable
[
https://issues.apache.org/jira/browse/CALCITE-2708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-2708:
-
Summary: In MATCH_RECOGNIZE, validator must ensure that arguments to a
user-defined aggregate function come from a single pattern variable (was:
UDAGs are not verified for single pattern variable in MATCH_RECOGNIZE)
> In MATCH_RECOGNIZE, validator must ensure that arguments to a user-defined
> aggregate function come from a single pattern variable
> -
>
> Key: CALCITE-2708
> URL: https://issues.apache.org/jira/browse/CALCITE-2708
> Project: Calcite
> Issue Type: Bug
>Reporter: Dawid Wysakowicz
>Assignee: Julian Hyde
>Priority: Major
> Labels: match
>
> Query:
> {code}
> SELECT *
> FROM Ticker
> MATCH_RECOGNIZE (
> ORDER BY proctime
> MEASURES
> udagg(A.price + B.tax) AS taxedPrice
> PATTERN (A B)
> DEFINE
> A AS A.symbol = 'a'
> ) AS T
> {code}
> should fail with ValidationException, because udagg is applied to different
> pattern variables.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2701) Make generated Baz classes immutable
[
https://issues.apache.org/jira/browse/CALCITE-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16699648#comment-16699648
]
Stamatis Zampetakis commented on CALCITE-2701:
--
By immutable, I was referring to the instances of the Baz classes produced by
Janino. My main problem is the instance variable root that gets assigned every
time the bind method is called.
Regarding the JANINO-169, as I wrote in the description the best I could find
is this
[commit|https://github.com/janino-compiler/janino/commit/fe5edc1904278c1c189f3379e06417aaf4a26315].
I couldn't even find the description of the actual issue.
> 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
>Priority: Major
> Labels: pull-request-available
> 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] [Created] (CALCITE-2710) Some SqlFunctions use LOCAL_TZ constant instead of using timeZone()
Andrew Pilloud created CALCITE-2710: --- Summary: Some SqlFunctions use LOCAL_TZ constant instead of using timeZone() Key: CALCITE-2710 URL: https://issues.apache.org/jira/browse/CALCITE-2710 Project: Calcite Issue Type: Bug Components: core Reporter: Andrew Pilloud Assignee: Julian Hyde There are several methods in SqlFunctions which use a LOCAL_TZ constant to determine the file. This constant is the default system time zone, but the local time zone can be modified on the connection. This results in incorrect behavior if the system time zone and connection time zone differ, for example adding an offset and removing a different offset. These functions should be calling the timeZone method which fetches the local timezone from the DataContext. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2710) Some SqlFunctions use LOCAL_TZ constant instead of using timeZone()
[ https://issues.apache.org/jira/browse/CALCITE-2710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16699679#comment-16699679 ] Andrew Pilloud commented on CALCITE-2710: - I think this is just a plumbing issue, I plan to work on it shortly. > Some SqlFunctions use LOCAL_TZ constant instead of using timeZone() > --- > > Key: CALCITE-2710 > URL: https://issues.apache.org/jira/browse/CALCITE-2710 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Andrew Pilloud >Assignee: Julian Hyde >Priority: Major > > There are several methods in SqlFunctions which use a LOCAL_TZ constant to > determine the file. This constant is the default system time zone, but the > local time zone can be modified on the connection. This results in incorrect > behavior if the system time zone and connection time zone differ, for example > adding an offset and removing a different offset. These functions should be > calling the timeZone method which fetches the local timezone from the > DataContext. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2698) Use docker hub hooks to select Avatica version during build and publish HSQLDB Avatica image
[ https://issues.apache.org/jira/browse/CALCITE-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16699584#comment-16699584 ] ASF GitHub Bot commented on CALCITE-2698: - Github user F21 commented on the issue: https://github.com/apache/calcite-avatica/pull/79 @risdenk I tested the hooks on my own docker repos. See the built images here: This repository is the automated build of the avatica base image: - https://hub.docker.com/r/f21global/calcite-avatica-test/ The following 2 are demonstrations of the HSQLDB flavor of avatica triggered using hooks: - https://hub.docker.com/r/f21global/calcite-avatica-hypersql-test2/ - https://hub.docker.com/r/f21global/calcite-avatica-hypersql-test1/ > Use docker hub hooks to select Avatica version during build and publish > HSQLDB Avatica image > > > Key: CALCITE-2698 > URL: https://issues.apache.org/jira/browse/CALCITE-2698 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Francis Chuang >Assignee: Francis Chuang >Priority: Major > Fix For: avatica-1.13.0 > > > Also remove changes from CALCITE-2385 (-DskipDockerCheck) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
