[jira] [Commented] (IGNITE-16631) ODBC: Add ability to set default query, calcite or H2, engine on DSN configuration or connection string
[ https://issues.apache.org/jira/browse/IGNITE-16631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17501301#comment-17501301 ] Aleksey Plekhanov commented on IGNITE-16631: [~ivandasch], i've looked at java part, it looks good to me. > ODBC: Add ability to set default query, calcite or H2, engine on DSN > configuration or connection string > --- > > Key: IGNITE-16631 > URL: https://issues.apache.org/jira/browse/IGNITE-16631 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Major > Labels: calcite, calcite2-required > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (IGNITE-16632) Calcite engine. Add calcite dependencies to TC build
[
https://issues.apache.org/jira/browse/IGNITE-16632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17501012#comment-17501012
]
Aleksey Plekhanov edited comment on IGNITE-16632 at 3/3/22, 8:50 PM:
-
[~vveider], tests passed, thanks for the fix!
was (Author: alex_pl):
[~alex_pl] tests passed, thanks for the fix!
> Calcite engine. Add calcite dependencies to TC build
>
>
> Key: IGNITE-16632
> URL: https://issues.apache.org/jira/browse/IGNITE-16632
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksey Plekhanov
>Assignee: Petr Ivanov
>Priority: Major
> Labels: build, calcite
>
> Currently, a limited set of JARs is included in build artifacts
> ([https://ci.ignite.apache.org/admin/editRunType.html?id=buildType:IgniteTests24Java8_Build=RUNNER_286]).
> There are some new external dependencies for the new calcite module, that
> should be added too. Some test suites can't pass without these dependencies
> (C++ for example: [https://ci.ignite.apache.org/viewLog.html?buildId=6435330])
> {noformat}
> zip -ur run modules/calcite/target/libs/calcite-*.jar \
> modules/calcite/target/libs/avatica-*.jar \
> modules/calcite/target/libs/checker-qual-*.jar \
> modules/calcite/target/libs/commons-compiler-*.jar \
> modules/calcite/target/libs/esri-geometry-*.jar \
> modules/calcite/target/libs/guava-*.jar \
> modules/calcite/target/libs/janino-*.jar \
> modules/calcite/target/libs/json-path-*.jar {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16632) Calcite engine. Add calcite dependencies to TC build
[
https://issues.apache.org/jira/browse/IGNITE-16632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17501012#comment-17501012
]
Aleksey Plekhanov commented on IGNITE-16632:
[~alex_pl] tests passed, thanks for the fix!
> Calcite engine. Add calcite dependencies to TC build
>
>
> Key: IGNITE-16632
> URL: https://issues.apache.org/jira/browse/IGNITE-16632
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksey Plekhanov
>Assignee: Petr Ivanov
>Priority: Major
> Labels: build, calcite
>
> Currently, a limited set of JARs is included in build artifacts
> ([https://ci.ignite.apache.org/admin/editRunType.html?id=buildType:IgniteTests24Java8_Build=RUNNER_286]).
> There are some new external dependencies for the new calcite module, that
> should be added too. Some test suites can't pass without these dependencies
> (C++ for example: [https://ci.ignite.apache.org/viewLog.html?buildId=6435330])
> {noformat}
> zip -ur run modules/calcite/target/libs/calcite-*.jar \
> modules/calcite/target/libs/avatica-*.jar \
> modules/calcite/target/libs/checker-qual-*.jar \
> modules/calcite/target/libs/commons-compiler-*.jar \
> modules/calcite/target/libs/esri-geometry-*.jar \
> modules/calcite/target/libs/guava-*.jar \
> modules/calcite/target/libs/janino-*.jar \
> modules/calcite/target/libs/json-path-*.jar {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16652) Calcite engine. Fix minor issues for green TC bot visa
Aleksey Plekhanov created IGNITE-16652:
--
Summary: Calcite engine. Fix minor issues for green TC bot visa
Key: IGNITE-16652
URL: https://issues.apache.org/jira/browse/IGNITE-16652
Project: Ignite
Issue Type: Task
Reporter: Aleksey Plekhanov
* JDBC compatibility test fails for 2.9+ Ignite versions
* STATISTICS_GLOBAL_DATA system view should be added to tests
* .NET tests failed due to missing {{org.hamcrest}} dependency
* JavaDoc suite failed due to incorrect {{@inheritDoc}} tag usage
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16652) Calcite engine. Fix minor issues for green TC bot visa
[
https://issues.apache.org/jira/browse/IGNITE-16652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-16652:
--
Assignee: Aleksey Plekhanov
> Calcite engine. Fix minor issues for green TC bot visa
> --
>
> Key: IGNITE-16652
> URL: https://issues.apache.org/jira/browse/IGNITE-16652
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required
>
> * JDBC compatibility test fails for 2.9+ Ignite versions
> * STATISTICS_GLOBAL_DATA system view should be added to tests
> * .NET tests failed due to missing {{org.hamcrest}} dependency
> * JavaDoc suite failed due to incorrect {{@inheritDoc}} tag usage
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16072) Add configurable throttling for the spanshot process
[ https://issues.apache.org/jira/browse/IGNITE-16072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500785#comment-17500785 ] Aleksey Plekhanov commented on IGNITE-16072: [~xtern], LGTM > Add configurable throttling for the spanshot process > > > Key: IGNITE-16072 > URL: https://issues.apache.org/jira/browse/IGNITE-16072 > Project: Ignite > Issue Type: Improvement >Reporter: Maxim Muzafarov >Assignee: Pavel Pereslegin >Priority: Major > Labels: iep-43, ise > Fix For: 2.13 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > We want to add configurable throttling to the number of threads that perform > a snapshot operation. The IGNITE-16014 have introduced the pool size > configuration property, however, it is still possible that a node can become > overloaded and unresponsive due to its attempts to copy data files on very > slow HDDs. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16632) Calcite engine. Add calcite dependencies to TC build
[
https://issues.apache.org/jira/browse/IGNITE-16632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499427#comment-17499427
]
Aleksey Plekhanov commented on IGNITE-16632:
[~vveider], one more suite with the same problem: "Start Nodes"
([https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_StartNodes])
> Calcite engine. Add calcite dependencies to TC build
>
>
> Key: IGNITE-16632
> URL: https://issues.apache.org/jira/browse/IGNITE-16632
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksey Plekhanov
>Assignee: Petr Ivanov
>Priority: Major
> Labels: build, calcite
>
> Currently, a limited set of JARs is included in build artifacts
> ([https://ci.ignite.apache.org/admin/editRunType.html?id=buildType:IgniteTests24Java8_Build=RUNNER_286]).
> There are some new external dependencies for the new calcite module, that
> should be added too. Some test suites can't pass without these dependencies
> (C++ for example: [https://ci.ignite.apache.org/viewLog.html?buildId=6435330])
> {noformat}
> zip -ur run modules/calcite/target/libs/calcite-*.jar \
> modules/calcite/target/libs/avatica-*.jar \
> modules/calcite/target/libs/checker-qual-*.jar \
> modules/calcite/target/libs/commons-compiler-*.jar \
> modules/calcite/target/libs/esri-geometry-*.jar \
> modules/calcite/target/libs/guava-*.jar \
> modules/calcite/target/libs/janino-*.jar \
> modules/calcite/target/libs/json-path-*.jar {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16632) Calcite engine. Add calcite dependencies to TC build
[
https://issues.apache.org/jira/browse/IGNITE-16632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17498846#comment-17498846
]
Aleksey Plekhanov commented on IGNITE-16632:
[~vveider], currently, I've faced with this problem only for C++ builds
(Platform C++ CMake (Win x64 | Release), Platform C++ CMake (Linux), Platform
C++ CMake (Linux CLang))
> Calcite engine. Add calcite dependencies to TC build
>
>
> Key: IGNITE-16632
> URL: https://issues.apache.org/jira/browse/IGNITE-16632
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksey Plekhanov
>Assignee: Petr Ivanov
>Priority: Major
> Labels: build, calcite
>
> Currently, a limited set of JARs is included in build artifacts
> ([https://ci.ignite.apache.org/admin/editRunType.html?id=buildType:IgniteTests24Java8_Build=RUNNER_286]).
> There are some new external dependencies for the new calcite module, that
> should be added too. Some test suites can't pass without these dependencies
> (C++ for example: [https://ci.ignite.apache.org/viewLog.html?buildId=6435330])
> {noformat}
> zip -ur run modules/calcite/target/libs/calcite-*.jar \
> modules/calcite/target/libs/avatica-*.jar \
> modules/calcite/target/libs/checker-qual-*.jar \
> modules/calcite/target/libs/commons-compiler-*.jar \
> modules/calcite/target/libs/esri-geometry-*.jar \
> modules/calcite/target/libs/guava-*.jar \
> modules/calcite/target/libs/janino-*.jar \
> modules/calcite/target/libs/json-path-*.jar {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16632) Calcite engine. Add calcite dependencies to TC build
[
https://issues.apache.org/jira/browse/IGNITE-16632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17498839#comment-17498839
]
Aleksey Plekhanov commented on IGNITE-16632:
[~vveider], build config
([https://ci.ignite.apache.org/admin/editBuildRunners.html?id=buildType:IgniteTests24Java8_Build]),
step 10.
> Calcite engine. Add calcite dependencies to TC build
>
>
> Key: IGNITE-16632
> URL: https://issues.apache.org/jira/browse/IGNITE-16632
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksey Plekhanov
>Assignee: Petr Ivanov
>Priority: Major
> Labels: build, calcite
>
> Currently, a limited set of JARs is included in build artifacts
> ([https://ci.ignite.apache.org/admin/editRunType.html?id=buildType:IgniteTests24Java8_Build=RUNNER_286]).
> There are some new external dependencies for the new calcite module, that
> should be added too. Some test suites can't pass without these dependencies
> (C++ for example: [https://ci.ignite.apache.org/viewLog.html?buildId=6435330])
> {noformat}
> zip -ur run modules/calcite/target/libs/calcite-*.jar \
> modules/calcite/target/libs/avatica-*.jar \
> modules/calcite/target/libs/checker-qual-*.jar \
> modules/calcite/target/libs/commons-compiler-*.jar \
> modules/calcite/target/libs/esri-geometry-*.jar \
> modules/calcite/target/libs/guava-*.jar \
> modules/calcite/target/libs/janino-*.jar \
> modules/calcite/target/libs/json-path-*.jar {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16632) Calcite engine. Add calcite dependencies to TC build
Aleksey Plekhanov created IGNITE-16632:
--
Summary: Calcite engine. Add calcite dependencies to TC build
Key: IGNITE-16632
URL: https://issues.apache.org/jira/browse/IGNITE-16632
Project: Ignite
Issue Type: Task
Reporter: Aleksey Plekhanov
Currently, a limited set of JARs is included in build artifacts
([https://ci.ignite.apache.org/admin/editRunType.html?id=buildType:IgniteTests24Java8_Build=RUNNER_286]).
There are some new external dependencies for the new calcite module, that
should be added too. Some test suites can't pass without these dependencies
(C++ for example: [https://ci.ignite.apache.org/viewLog.html?buildId=6435330])
{noformat}
zip -ur run modules/calcite/target/libs/calcite-*.jar \
modules/calcite/target/libs/avatica-*.jar \
modules/calcite/target/libs/checker-qual-*.jar \
modules/calcite/target/libs/commons-compiler-*.jar \
modules/calcite/target/libs/esri-geometry-*.jar \
modules/calcite/target/libs/guava-*.jar \
modules/calcite/target/libs/janino-*.jar \
modules/calcite/target/libs/json-path-*.jar {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16632) Calcite engine. Add calcite dependencies to TC build
[
https://issues.apache.org/jira/browse/IGNITE-16632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17498819#comment-17498819
]
Aleksey Plekhanov commented on IGNITE-16632:
[~vveider], can you please change the settings?
> Calcite engine. Add calcite dependencies to TC build
>
>
> Key: IGNITE-16632
> URL: https://issues.apache.org/jira/browse/IGNITE-16632
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksey Plekhanov
>Priority: Major
> Labels: build, calcite
>
> Currently, a limited set of JARs is included in build artifacts
> ([https://ci.ignite.apache.org/admin/editRunType.html?id=buildType:IgniteTests24Java8_Build=RUNNER_286]).
> There are some new external dependencies for the new calcite module, that
> should be added too. Some test suites can't pass without these dependencies
> (C++ for example: [https://ci.ignite.apache.org/viewLog.html?buildId=6435330])
> {noformat}
> zip -ur run modules/calcite/target/libs/calcite-*.jar \
> modules/calcite/target/libs/avatica-*.jar \
> modules/calcite/target/libs/checker-qual-*.jar \
> modules/calcite/target/libs/commons-compiler-*.jar \
> modules/calcite/target/libs/esri-geometry-*.jar \
> modules/calcite/target/libs/guava-*.jar \
> modules/calcite/target/libs/janino-*.jar \
> modules/calcite/target/libs/json-path-*.jar {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-14195) SQL Calcite: ease of use of new Calcite engine
[ https://issues.apache.org/jira/browse/IGNITE-14195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-14195: --- Labels: calcite calcite3-required (was: calcite2-required calcite3-required) > SQL Calcite: ease of use of new Calcite engine > -- > > Key: IGNITE-14195 > URL: https://issues.apache.org/jira/browse/IGNITE-14195 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Aleksey Plekhanov >Priority: Major > Labels: calcite, calcite3-required > Time Spent: 1h 10m > Remaining Estimate: 0h > > As of now, we don't have an easy way to use the Calcite engine. The proposal > is following, add some 'hint' or preffix for SQL query which will force to > use the new engine independent of using API (Java, JDBC, ). > For example: /*+ CALCITE_ENGINE */ SELECT * FROM table; -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-14195) SQL Calcite: ease of use of new Calcite engine
[ https://issues.apache.org/jira/browse/IGNITE-14195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17495923#comment-17495923 ] Aleksey Plekhanov commented on IGNITE-14195: [~ivandasch], thanks for the review! Merged to sql-calcite branch. > SQL Calcite: ease of use of new Calcite engine > -- > > Key: IGNITE-14195 > URL: https://issues.apache.org/jira/browse/IGNITE-14195 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Aleksey Plekhanov >Priority: Major > Labels: calcite2-required, calcite3-required > Time Spent: 1h 10m > Remaining Estimate: 0h > > As of now, we don't have an easy way to use the Calcite engine. The proposal > is following, add some 'hint' or preffix for SQL query which will force to > use the new engine independent of using API (Java, JDBC, ). > For example: /*+ CALCITE_ENGINE */ SELECT * FROM table; -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16580) Calcite. Merge returns unexpected results.
[
https://issues.apache.org/jira/browse/IGNITE-16580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17495353#comment-17495353
]
Aleksey Plekhanov commented on IGNITE-16580:
[~zstan], I've checked the query and it returns the correct result. The result
is not the same as you expect in code since column "c" is not inserted and its
value is {{null}} for the '222, 222' row (also k2 is inserted into k1 column,
but it does not affect the result). Result will be as expected if something
like this will be used as an insert statement: {{{}INSERT (k1, k2, a, b, c)
VALUES (src.k1, src.k2, src.a, src.b, src.c){}}}.
> Calcite. Merge returns unexpected results.
> --
>
> Key: IGNITE-16580
> URL: https://issues.apache.org/jira/browse/IGNITE-16580
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeny Stanilovsky
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, calcite2-required
>
> {noformat}
> @Test
> public void testMerge0() {
> sql("CREATE TABLE test1 (k1 int, k2 int, a int, b varchar, c varchar,
> CONSTRAINT PK PRIMARY KEY (k1, k2))");
> sql("INSERT INTO test1 VALUES (111, 111, 0, 'a', '0')");
> sql("INSERT INTO test1 VALUES (222, 222, 1, 'b', '1')");
> sql("CREATE TABLE test2 (k1 int, k2 int, a int, b varchar, c varchar,
> CONSTRAINT PK PRIMARY KEY (k1, k2))");
> sql("INSERT INTO test2 VALUES (333, 333, 0, '100', '')");
> sql("INSERT INTO test2 VALUES (444, 444, 2, '200', '')");
> String sql = "MERGE INTO test2 dst USING test1 src ON (dst.a = src.a)
> " +
> "WHEN MATCHED THEN UPDATE SET b = src.b " +
> "WHEN NOT MATCHED THEN INSERT (k1, k2, a, b) VALUES (src.k2,
> src.k2, src.a, src.b)";
>
> assertQuery(sql).matches(QueryChecker.containsSubPlan("IgniteTableSpool")).check();
> assertQuery("SELECT * FROM test2 ORDER BY k1")
> .returns(222, 222, 1, "b", "1")
> .returns(333, 333, 0, "a", "")
> .returns(444, 444, 2, "200", "")
> .check();
> }
> {noformat}
> java.lang.AssertionError: Collections sizes are not equal:
> Expected: [[222, 222, 1, b, 1], [333, 333, 0, a, ], [444, 444, 2, 200, ]]
> Actual: [[333, 333, 0, 100, ], [444, 444, 2, 200, ]]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16580) Calcite. Merge returns unexpected results.
[
https://issues.apache.org/jira/browse/IGNITE-16580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-16580:
--
Assignee: Aleksey Plekhanov
> Calcite. Merge returns unexpected results.
> --
>
> Key: IGNITE-16580
> URL: https://issues.apache.org/jira/browse/IGNITE-16580
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeny Stanilovsky
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, calcite2-required
>
> {noformat}
> @Test
> public void testMerge0() {
> sql("CREATE TABLE test1 (k1 int, k2 int, a int, b varchar, c varchar,
> CONSTRAINT PK PRIMARY KEY (k1, k2))");
> sql("INSERT INTO test1 VALUES (111, 111, 0, 'a', '0')");
> sql("INSERT INTO test1 VALUES (222, 222, 1, 'b', '1')");
> sql("CREATE TABLE test2 (k1 int, k2 int, a int, b varchar, c varchar,
> CONSTRAINT PK PRIMARY KEY (k1, k2))");
> sql("INSERT INTO test2 VALUES (333, 333, 0, '100', '')");
> sql("INSERT INTO test2 VALUES (444, 444, 2, '200', '')");
> String sql = "MERGE INTO test2 dst USING test1 src ON (dst.a = src.a)
> " +
> "WHEN MATCHED THEN UPDATE SET b = src.b " +
> "WHEN NOT MATCHED THEN INSERT (k1, k2, a, b) VALUES (src.k2,
> src.k2, src.a, src.b)";
>
> assertQuery(sql).matches(QueryChecker.containsSubPlan("IgniteTableSpool")).check();
> assertQuery("SELECT * FROM test2 ORDER BY k1")
> .returns(222, 222, 1, "b", "1")
> .returns(333, 333, 0, "a", "")
> .returns(444, 444, 2, "200", "")
> .check();
> }
> {noformat}
> java.lang.AssertionError: Collections sizes are not equal:
> Expected: [[222, 222, 1, b, 1], [333, 333, 0, a, ], [444, 444, 2, 200, ]]
> Actual: [[333, 333, 0, 100, ], [444, 444, 2, 200, ]]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16493) Calcite engine. Decorrelation after subquery rewrite
[
https://issues.apache.org/jira/browse/IGNITE-16493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17494024#comment-17494024
]
Aleksey Plekhanov commented on IGNITE-16493:
Looks like there are some problems in decorrelation procedure in Calcite, for
example, query:
{noformat}
CREATE TABLE integers(i INTEGER) WITH TEMPLATE=REPLICATED;
INSERT INTO integers VALUES (1), (2), (3), (NULL);
SELECT i, EXISTS(SELECT i FROM integers WHERE i IS NULL OR i>i1.i*10) FROM
integers i1;{noformat}
Produces plan like:
{noformat}
IgniteProject(I=[$2], EXPR$1=[IS NOT NULL($5)]): rowcount = 4.15, cumulative
cost = IgniteCost [rowCount=37.15, cpu=73.15, memory=28.0, io=0.0,
network=0.0], id = 3318
IgniteNestedLoopJoin(condition=[=($3, $4)], joinType=[left],
variablesSet=[[]]): rowcount = 4.15, cumulative cost = IgniteCost
[rowCount=33.0, cpu=69.0, memory=28.0, io=0.0, network=0.0], id = 3317
IgniteTableScan(table=[[PUBLIC, INTEGERS]], projects=[[$t0, $t1, $t2,
*($t2, 10)]], requiredColumns=[{0, 1, 2}]): rowcount = 4.0, cumulative cost =
IgniteCost [rowCount=4.0, cpu=4.0, memory=0.0, io=0.0, network=0.0], id = 1048
IgniteProject($f3=[$0], $f1=[true]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=25.0, cpu=49.0, memory=20.0, io=0.0, network=0.0], id =
3316
IgniteSingleHashAggregate(group=[{0}]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=24.0, cpu=48.0, memory=20.0, io=0.0, network=0.0], id =
3315
IgniteProject($f3=[$3]): rowcount = 2.0, cumulative cost = IgniteCost
[rowCount=22.0, cpu=46.0, memory=16.0, io=0.0, network=0.0], id = 3314
IgniteNestedLoopJoin(condition=[OR(IS NULL($2), >($2, $3))],
joinType=[inner], variablesSet=[[]]): rowcount = 2.0, cumulative cost =
IgniteCost [rowCount=20.0, cpu=44.0, memory=16.0, io=0.0, network=0.0], id =
3313
IgniteTableScan(table=[[PUBLIC, INTEGERS]]): rowcount = 4.0,
cumulative cost = IgniteCost [rowCount=4.0, cpu=4.0, memory=0.0, io=0.0,
network=0.0], id = 269
IgniteSingleHashAggregate(group=[{0}]): rowcount = 2.0, cumulative
cost = IgniteCost [rowCount=8.0, cpu=8.0, memory=8.0, io=0.0, network=0.0], id
= 3312
IgniteTableScan(table=[[PUBLIC, INTEGERS]], projects=[[*($t0,
10)]], requiredColumns=[{2}]): rowcount = 4.0, cumulative cost = IgniteCost
[rowCount=4.0, cpu=4.0, memory=0.0, io=0.0, network=0.0], id = 282{noformat}
In this plan {{IgniteNestedLoopJoin(condition=[=($3, $4)], joinType=[left])}}
filter out {{null}} values derived from the right hand and return wrong result
(\{{(null, false)}} instead of {{{}(null, true){}}})
> Calcite engine. Decorrelation after subquery rewrite
>
>
> Key: IGNITE-16493
> URL: https://issues.apache.org/jira/browse/IGNITE-16493
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required
>
> Currently decorrelation is performed in {{SqlToRelConverter}}, but after this
> {{PlannerPhase.HEP_DECORRELATE}} planning phase is executed (which actually
> rewrites subqueries into correlates, but doesn't perform decorrelation). In
> some cases, other types of join can cost less than correlated nested loop
> join, so we can try to decorrelate the query plan again after
> {{PlannerPhase.HEP_DECORRELATE}} phase (call
> {{RelDecorrelator.decorrelateQuery}}).
> {{PlannerPhase.HEP_DECORRELATE}} should be also renamed to something like
> "HEP_REWRITE_SUBQUERY".
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (IGNITE-15993) Calcite engine. Wrong result for single-value aggregation from empty source
[
https://issues.apache.org/jira/browse/IGNITE-15993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov resolved IGNITE-15993.
Resolution: Fixed
> Calcite engine. Wrong result for single-value aggregation from empty source
> ---
>
> Key: IGNITE-15993
> URL: https://issues.apache.org/jira/browse/IGNITE-15993
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Vladimir Steshin
>Priority: Minor
> Labels: calcite2-required, calcite3-required
> Time Spent: 20m
> Remaining Estimate: 0h
>
> For example:
> {noformat}
> SELECT (SELECT 1 FROM (SELECT 1) WHERE 1 = 0)
> {noformat}
> Returns 0, but expected {{{}NULL{}}}.
> With correlated queries result even more strange:
> {noformat}
> CREATE TABLE test (a INTEGER)
> INSERT INTO test VALUES (1), (2), (null)
> SELECT (SELECT 1 FROM test t WHERE a = test.a) FROM test
> {noformat}
> Returns 1, 1, 1 (expected 1, 1, NULL)
> Related test {{test_correlated_subquery.test_ignore}}
> From SQL standard:
> {noformat}
> Let SS be a .
> Case:
> a) If the cardinality of SS is greater than 1 (one), then an exception
> condition is raised: cardinality violation.
> b) If the cardinality of SS is 0 (zero), then the value of the subquery> is the null value.
> c) Otherwise, let C be the column of simply contained in
> SS. The value of SS is the value of C in the unique row of the result of the
> .{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15993) Calcite engine. Wrong result for single-value aggregation from empty source
[
https://issues.apache.org/jira/browse/IGNITE-15993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-15993:
---
Labels: calcite3-required (was: calcite2-required calcite3-required)
> Calcite engine. Wrong result for single-value aggregation from empty source
> ---
>
> Key: IGNITE-15993
> URL: https://issues.apache.org/jira/browse/IGNITE-15993
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Vladimir Steshin
>Priority: Minor
> Labels: calcite3-required
> Time Spent: 20m
> Remaining Estimate: 0h
>
> For example:
> {noformat}
> SELECT (SELECT 1 FROM (SELECT 1) WHERE 1 = 0)
> {noformat}
> Returns 0, but expected {{{}NULL{}}}.
> With correlated queries result even more strange:
> {noformat}
> CREATE TABLE test (a INTEGER)
> INSERT INTO test VALUES (1), (2), (null)
> SELECT (SELECT 1 FROM test t WHERE a = test.a) FROM test
> {noformat}
> Returns 1, 1, 1 (expected 1, 1, NULL)
> Related test {{test_correlated_subquery.test_ignore}}
> From SQL standard:
> {noformat}
> Let SS be a .
> Case:
> a) If the cardinality of SS is greater than 1 (one), then an exception
> condition is raised: cardinality violation.
> b) If the cardinality of SS is 0 (zero), then the value of the subquery> is the null value.
> c) Otherwise, let C be the column of simply contained in
> SS. The value of SS is the value of C in the unique row of the result of the
> .{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-15993) Calcite engine. Wrong result for single-value aggregation from empty source
[
https://issues.apache.org/jira/browse/IGNITE-15993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17493660#comment-17493660
]
Aleksey Plekhanov commented on IGNITE-15993:
[~vladsz83], thanks for the review! Merged to sql-calcite branch.
> Calcite engine. Wrong result for single-value aggregation from empty source
> ---
>
> Key: IGNITE-15993
> URL: https://issues.apache.org/jira/browse/IGNITE-15993
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Vladimir Steshin
>Priority: Minor
> Labels: calcite2-required, calcite3-required
> Time Spent: 20m
> Remaining Estimate: 0h
>
> For example:
> {noformat}
> SELECT (SELECT 1 FROM (SELECT 1) WHERE 1 = 0)
> {noformat}
> Returns 0, but expected {{{}NULL{}}}.
> With correlated queries result even more strange:
> {noformat}
> CREATE TABLE test (a INTEGER)
> INSERT INTO test VALUES (1), (2), (null)
> SELECT (SELECT 1 FROM test t WHERE a = test.a) FROM test
> {noformat}
> Returns 1, 1, 1 (expected 1, 1, NULL)
> Related test {{test_correlated_subquery.test_ignore}}
> From SQL standard:
> {noformat}
> Let SS be a .
> Case:
> a) If the cardinality of SS is greater than 1 (one), then an exception
> condition is raised: cardinality violation.
> b) If the cardinality of SS is 0 (zero), then the value of the subquery> is the null value.
> c) Otherwise, let C be the column of simply contained in
> SS. The value of SS is the value of C in the unique row of the result of the
> .{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16396) Calcite engine. Allow hash output distribution for aggregations
[
https://issues.apache.org/jira/browse/IGNITE-16396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17493342#comment-17493342
]
Aleksey Plekhanov commented on IGNITE-16396:
[~zstan], [~tledkov-gridgain], [~korlov], can you please review the patch?
> Calcite engine. Allow hash output distribution for aggregations
>
>
> Key: IGNITE-16396
> URL: https://issues.apache.org/jira/browse/IGNITE-16396
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, calcite3-required
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, we allow only single output distribution for aggregates, but looks
> like if we have hash input distribution and all grouping set contains all of
> the distribution keys we can make aggregation on remote nodes and produce
> hash output distribution with the same keys. This will reduce memory
> consumption on the initiator node and make some other optimizations possible.
> For example, query:
> {noformat}
> SELECT t1.aff_key, t2.cnt FROM t1 JOIN (SELECT aff_key, COUNT(*) AS cnt FROM
> t2 GROUP BY id) AS t2 ON t1.aff_key = t2.aff_key{noformat}
> Can do colocated join if both tables are colocated on {{{}aff_key{}}}.
> Currently, such a query does join on the initiator node.
> The same for set-ops (EXCEPT, INTERSECT).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-15584) Calcite. Failed to parse query with IN and simple subquery.
[
https://issues.apache.org/jira/browse/IGNITE-15584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492516#comment-17492516
]
Aleksey Plekhanov commented on IGNITE-15584:
[~zstan], [~ivandasch] it's not in a standard and I think it's strange syntax,
doubt we should support it. Let's just rewrite this test using supported
syntax. If someone will require such a syntax in the future it's better to
create a new ticket (with proper motivation).
> Calcite. Failed to parse query with IN and simple subquery.
> ---
>
> Key: IGNITE-15584
> URL: https://issues.apache.org/jira/browse/IGNITE-15584
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required, ignite-3
>
> {noformat}
> query I
> SELECT 1 AS one WHERE 1 IN (SELECT 1);
>
> 1
> statement ok
> CREATE TABLE tbl(a TINYINT, b SMALLINT, c INTEGER, d BIGINT, e VARCHAR, f
> DATE, g TIMESTAMP)
> statement ok
> INSERT INTO tbl VALUES (1, 2, 3, 4, '5', DATE '1992-01-01', TIMESTAMP
> '1992-01-01 00:00:00')
> query T
> SELECT EXISTS(SELECT t1.c,t1.d WHERE t1.d<100) FROM tbl t1
>
> true
> {noformat}
> {noformat}
> class org.apache.ignite.IgniteException: Error at: (t.test:14). sql: SELECT 1
> AS one WHERE 1 IN (SELECT 1);
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.execute(SqlScriptRunner.java:562)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.run(SqlScriptRunner.java:115)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.ScriptTestRunner$1.run(ScriptTestRunner.java:219)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> parse query.
> at
> org.apache.ignite.internal.processors.query.calcite.util.Commons.parse(Commons.java:205)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executeQuery(ExecutionServiceImpl.java:390)
> at
> org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.query(CalciteQueryProcessor.java:276)
> {noformat}
> {noformat}
> /any_all/test_simple_not_in.test[_ignore]
> /subquery/scalar/test_complex_nested_correlated_subquery.test[_ignore]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (IGNITE-13035) Calcite integration. Support fallback on indexes rebuild
[ https://issues.apache.org/jira/browse/IGNITE-13035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov resolved IGNITE-13035. Resolution: Duplicate Resolved by IGNITE-16111 > Calcite integration. Support fallback on indexes rebuild > > > Key: IGNITE-13035 > URL: https://issues.apache.org/jira/browse/IGNITE-13035 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Roman Kondakov >Priority: Minor > Labels: calcite2-required, calcite3-required > > When indexes are being rebuilt we need to use CacheTree for index scans as it > happens in legacy engine. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-13035) Calcite integration. Support fallback on indexes rebuild
[ https://issues.apache.org/jira/browse/IGNITE-13035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-13035: --- Labels: calcite (was: ) > Calcite integration. Support fallback on indexes rebuild > > > Key: IGNITE-13035 > URL: https://issues.apache.org/jira/browse/IGNITE-13035 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Roman Kondakov >Priority: Minor > Labels: calcite > > When indexes are being rebuilt we need to use CacheTree for index scans as it > happens in legacy engine. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-13035) Calcite integration. Support fallback on indexes rebuild
[ https://issues.apache.org/jira/browse/IGNITE-13035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-13035: --- Labels: (was: calcite2-required calcite3-required) > Calcite integration. Support fallback on indexes rebuild > > > Key: IGNITE-13035 > URL: https://issues.apache.org/jira/browse/IGNITE-13035 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Roman Kondakov >Priority: Minor > > When indexes are being rebuilt we need to use CacheTree for index scans as it > happens in legacy engine. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16111) Calcite engine. Fallback to table scan if index is absent on some nodes
[ https://issues.apache.org/jira/browse/IGNITE-16111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-16111: --- Labels: calcite calcite3-required (was: calcite2-required calcite3-required) > Calcite engine. Fallback to table scan if index is absent on some nodes > --- > > Key: IGNITE-16111 > URL: https://issues.apache.org/jira/browse/IGNITE-16111 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: calcite, calcite3-required > Time Spent: 4h 50m > Remaining Estimate: 0h > > Calcite-based SQL engine creates a plan on node initiator and uses only local > node data for planning. The local node doesn't know about other nodes' > indexes state, indexes on some nodes can be rebuilt during query execution, > and fragments of the plan containing rebuilding indexes can't be executed on > these nodes. In this case, we should provide some type of fallback. For > example, if the status of the index is invalid and the plan contains an index > scan, we should replace this index scan with the chain: sorted index spool -> > sort -> table scan. > As a target solution, perhaps we should maintain global indexes state and > make plans using this information -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-14916) Calcite. RuntimeHashIndex scan must filter result by predicate
[ https://issues.apache.org/jira/browse/IGNITE-14916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492134#comment-17492134 ] Aleksey Plekhanov commented on IGNITE-14916: [~tledkov-gridgain] LGTM. > Calcite. RuntimeHashIndex scan must filter result by predicate > -- > > Key: IGNITE-14916 > URL: https://issues.apache.org/jira/browse/IGNITE-14916 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Evgeny Stanilovsky >Assignee: Taras Ledkov >Priority: Major > Labels: calcite, calcite2-required, calcite3-required > Time Spent: 40m > Remaining Estimate: 0h > > FilterSpoolMergeToHashIndexSpoolRule can return erroneous results cause it > takes into account only _searchRow_ which can be partial representation of > _condition_. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16511) Calcite engine. Move system properties constants to IgniteSystemProperties class
[
https://issues.apache.org/jira/browse/IGNITE-16511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16511:
---
Labels: calcite calcite3-required (was: calcite calcite2-required
calcite3-required)
> Calcite engine. Move system properties constants to IgniteSystemProperties
> class
> -
>
> Key: IGNITE-16511
> URL: https://issues.apache.org/jira/browse/IGNITE-16511
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, calcite3-required
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> We have a set of system properties constants for the Calcite-based SQL
> engine, which are placed in different classes and not documented:
> {noformat}
> IGNITE_CALCITE_EXEC_IN_BUFFER_SIZE
> IGNITE_CALCITE_EXEC_BATCH_SIZE
> IGNITE_CALCITE_EXEC_IO_BATCH_SIZE
> IGNITE_CALCITE_EXEC_IO_BATCH_CNT
> IGNITE_CALCITE_REL_JSON_PRETTY_PRINT{noformat}
> They should be moved to {{IgniteSystemProperties}} class with a proper
> {{@SystemProperty}} annotation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-14916) Calcite. RuntimeHashIndex scan must filter result by predicate
[ https://issues.apache.org/jira/browse/IGNITE-14916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490749#comment-17490749 ] Aleksey Plekhanov commented on IGNITE-14916: [~tledkov-gridgain] pull request is not attached. > Calcite. RuntimeHashIndex scan must filter result by predicate > -- > > Key: IGNITE-14916 > URL: https://issues.apache.org/jira/browse/IGNITE-14916 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Evgeny Stanilovsky >Assignee: Taras Ledkov >Priority: Major > Labels: calcite, calcite2-required, calcite3-required > > FilterSpoolMergeToHashIndexSpoolRule can return erroneous results cause it > takes into account only _searchRow_ which can be partial representation of > _condition_. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-16511) Calcite engine. Move system properties constants to IgniteSystemProperties class
[
https://issues.apache.org/jira/browse/IGNITE-16511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-16511:
--
Assignee: Aleksey Plekhanov
> Calcite engine. Move system properties constants to IgniteSystemProperties
> class
> -
>
> Key: IGNITE-16511
> URL: https://issues.apache.org/jira/browse/IGNITE-16511
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have a set of system properties constants for the Calcite-based SQL
> engine, which are placed in different classes and not documented:
> {noformat}
> IGNITE_CALCITE_EXEC_IN_BUFFER_SIZE
> IGNITE_CALCITE_EXEC_BATCH_SIZE
> IGNITE_CALCITE_EXEC_IO_BATCH_SIZE
> IGNITE_CALCITE_EXEC_IO_BATCH_CNT
> IGNITE_CALCITE_REL_JSON_PRETTY_PRINT{noformat}
> They should be moved to {{IgniteSystemProperties}} class with a proper
> {{@SystemProperty}} annotation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-14916) Calcite. FilterSpoolMergeToHashIndexSpoolRule need to be applicable only if all conditions are covered.
[
https://issues.apache.org/jira/browse/IGNITE-14916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490213#comment-17490213
]
Aleksey Plekhanov commented on IGNITE-14916:
Reproducer for the problem:
{code:java}
/** */
@Test
public void testHashSpoolCondition() {
executeSql("CREATE TABLE t(i INTEGER)");
executeSql("INSERT INTO t VALUES (0), (1), (2)");
String sql = "SELECT i, (SELECT i FROM t WHERE i=t1.i AND i-1=0) FROM t AS
t1";
assertQuery(sql)
.matches(QueryChecker.containsSubPlan("IgniteHashIndexSpool"))
.returns(0, null)
.returns(1, 1)
.returns(2, null)
.check();
}{code}
[~tledkov-gridgain], are you going to fix this?
> Calcite. FilterSpoolMergeToHashIndexSpoolRule need to be applicable only if
> all conditions are covered.
> ---
>
> Key: IGNITE-14916
> URL: https://issues.apache.org/jira/browse/IGNITE-14916
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeny Stanilovsky
>Assignee: Taras Ledkov
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required
>
> FilterSpoolMergeToHashIndexSpoolRule can return erroneous results cause it
> takes into account only _searchRow_ which can be partial representation of
> _condition_.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16505) Calcite engine. Move row count approximation from ignite-indexing
[
https://issues.apache.org/jira/browse/IGNITE-16505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16505:
---
Labels: calcite calcite3-required (was: calcite calcite2-required
calcite3-required)
> Calcite engine. Move row count approximation from ignite-indexing
> --
>
> Key: IGNITE-16505
> URL: https://issues.apache.org/jira/browse/IGNITE-16505
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, calcite3-required
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Method {{GridH2Table.getRowCountApproximationNoCheck}} was introduced only
> for the Calcite-based SQL engine. This method is not used by
> {{ignite-indexing}} module, this method doesn't use almost anything from
> {{ignite-indexing}} module. It can be easily moved {{ignite-calcite}} module,
> that allow to reduce dependencies from {{ignite-calcite}} to
> {{ignite-indexing}} and avoid merge conflicts.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16505) Calcite engine. Move row count approximation from ignite-indexing
[
https://issues.apache.org/jira/browse/IGNITE-16505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490011#comment-17490011
]
Aleksey Plekhanov commented on IGNITE-16505:
[~zstan], thanks for the review! Merged to sql-calcite branch.
> Calcite engine. Move row count approximation from ignite-indexing
> --
>
> Key: IGNITE-16505
> URL: https://issues.apache.org/jira/browse/IGNITE-16505
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Method {{GridH2Table.getRowCountApproximationNoCheck}} was introduced only
> for the Calcite-based SQL engine. This method is not used by
> {{ignite-indexing}} module, this method doesn't use almost anything from
> {{ignite-indexing}} module. It can be easily moved {{ignite-calcite}} module,
> that allow to reduce dependencies from {{ignite-calcite}} to
> {{ignite-indexing}} and avoid merge conflicts.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16511) Calcite engine. Move system properties constants to IgniteSystemProperties class
Aleksey Plekhanov created IGNITE-16511:
--
Summary: Calcite engine. Move system properties constants to
IgniteSystemProperties class
Key: IGNITE-16511
URL: https://issues.apache.org/jira/browse/IGNITE-16511
Project: Ignite
Issue Type: Task
Reporter: Aleksey Plekhanov
We have a set of system properties constants for the Calcite-based SQL engine,
which are placed in different classes and not documented:
{noformat}
IGNITE_CALCITE_EXEC_IN_BUFFER_SIZE
IGNITE_CALCITE_EXEC_BATCH_SIZE
IGNITE_CALCITE_EXEC_IO_BATCH_SIZE
IGNITE_CALCITE_EXEC_IO_BATCH_CNT
IGNITE_CALCITE_REL_JSON_PRETTY_PRINT{noformat}
They should be moved to {{IgniteSystemProperties}} class with a proper
{{@SystemProperty}} annotation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16510) Calcite engine. Support "keep binary" flag
Aleksey Plekhanov created IGNITE-16510: -- Summary: Calcite engine. Support "keep binary" flag Key: IGNITE-16510 URL: https://issues.apache.org/jira/browse/IGNITE-16510 Project: Ignite Issue Type: New Feature Reporter: Aleksey Plekhanov The "keep binary" flag is currently ignored by the Calcite-based SQL engine and there is no way to return a deserialized object: all POJO returned in binary format. We should support the "keep binary" flag and deserialize objects if needed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16509) Calcite engine. Support OTHER data type
Aleksey Plekhanov created IGNITE-16509:
--
Summary: Calcite engine. Support OTHER data type
Key: IGNITE-16509
URL: https://issues.apache.org/jira/browse/IGNITE-16509
Project: Ignite
Issue Type: New Feature
Reporter: Aleksey Plekhanov
Table with {{OTHER}} (Object) data type can be created by H2-based SQL engine:
{noformat}
CREATE TABLE t(val OTHER)
{noformat}
But such a data type is not supported by Calcite-based SQL engine (at least in
DDL)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16507) Calcite engine. Redundant sort node when rewriting index scan on index rebuild
Aleksey Plekhanov created IGNITE-16507:
--
Summary: Calcite engine. Redundant sort node when rewriting index
scan on index rebuild
Key: IGNITE-16507
URL: https://issues.apache.org/jira/browse/IGNITE-16507
Project: Ignite
Issue Type: Improvement
Reporter: Aleksey Plekhanov
When the query plan has an index scan, but the index is rebuilding we rewrite
this scan to the chain of table scan/sort/spool/project nodes (see
IGNITE-16111). In some cases sort node is redundant, but still created, for
example, when index scan is used only for filtering:
{noformat}
SELECT * FROM emp WHERE dep_id = 10
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16505) Calcite engine. Move row count approximation from ignite-indexing
Aleksey Plekhanov created IGNITE-16505:
--
Summary: Calcite engine. Move row count approximation from
ignite-indexing
Key: IGNITE-16505
URL: https://issues.apache.org/jira/browse/IGNITE-16505
Project: Ignite
Issue Type: Task
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Method {{GridH2Table.getRowCountApproximationNoCheck}} was introduced only for
the Calcite-based SQL engine. This method is not used by {{ignite-indexing}}
module, this method doesn't use almost anything from {{ignite-indexing}}
module. It can be easily moved {{ignite-calcite}} module, that allow to reduce
dependencies from {{ignite-calcite}} to {{ignite-indexing}} and avoid merge
conflicts.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16191) Calcite engine. Unexpected result of COUNT with multiple parameters
[
https://issues.apache.org/jira/browse/IGNITE-16191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488848#comment-17488848
]
Aleksey Plekhanov commented on IGNITE-16191:
[~Berkov], hmm, looks like you are right, perhaps I misread the calcite
documentation. But there still was an error with {{SELECT COUNT(null, null)}}
and the syntax looks confusing.
> Calcite engine. Unexpected result of COUNT with multiple parameters
> ---
>
> Key: IGNITE-16191
> URL: https://issues.apache.org/jira/browse/IGNITE-16191
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Aleksey Plekhanov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: calcite3-required
> Fix For: 2.13
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The calcite engine supports the {{COUNT}} aggregate function with multiple
> parameters. Such a function should return the number of input rows for which
> parameters are wholly not null.
> But currently queries like:
> {noformat}
> SELECT COUNT(null, 1)
> SELECT COUNT(1, null)
> {noformat}
> Return 0 (expected 1).
> Query:
> {noformat}
> SELECT COUNT(null, null)
> {noformat}
> Throw an exception:
> {noformat}
> Caused by: java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
> at java.util.ArrayList.rangeCheck(ArrayList.java:657)
> at java.util.ArrayList.get(ArrayList.java:433)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.agg.AccumulatorsFactory$WrapperPrototype$1.apply(AccumulatorsFactory.java:226)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.agg.AccumulatorsFactory$WrapperPrototype$1.apply(AccumulatorsFactory.java:223)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.agg.AccumulatorsFactory$AccumulatorWrapperImpl.add(AccumulatorsFactory.java:305)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.HashAggregateNode$Grouping.addOnMapper(HashAggregateNode.java:294)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.HashAggregateNode$Grouping.add(HashAggregateNode.java:265)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.HashAggregateNode$Grouping.access$100(HashAggregateNode.java:222)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.HashAggregateNode.push(HashAggregateNode.java:127)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.ScanNode.push(ScanNode.java:107)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16397) Calcite engine. Failed to insert to table with two or more columns in primary keys
[
https://issues.apache.org/jira/browse/IGNITE-16397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16397:
---
Labels: calcite calcite3-required (was: calcite2-required
calcite3-required)
> Calcite engine. Failed to insert to table with two or more columns in primary
> keys
> --
>
> Key: IGNITE-16397
> URL: https://issues.apache.org/jira/browse/IGNITE-16397
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, calcite3-required
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> For example:
> {noformat}
> CREATE TABLE t(id INT, val VARCHAR, PRIMARY KEY(id, val));
> INSERT INTO t(id, val) VALUES (1, 'a');
> {noformat}
> Fails with:
> {noformat}
> Failed processing message [senderId=8aec0b77-e5a2-49b5-8f77-0f0a7771,
> msg=GridNearAtomicUpdateResponse
> [nodeId=235d7fbc-2a05-4d8b-8e37-3dff3980fc76, futId=1, errs=null,
> ret=GridCacheReturn [v=HashMap
> {SQL_PUBLIC_T_a975cf68_1738_43ca_915b_a52e6b89c049_KEY [idHash=1524322354,
> hash=-904731590, VAL=a, ID=1]=CacheInvokeResult [res=1, err=null]},
> cacheObj=null, success=false, invokeRes=true, loc=true, cacheId=-1578586257],
> remapTopVer=null, nearUpdates=null, partId=552, mapping=ArrayList [],
> nodeLeft=false, super=GridCacheIdMessage [cacheId=-1578586257,
> super=GridCacheMessage [msgId=30, depInfo=null,
> lastAffChangedTopVer=AffinityTopologyVersion [topVer=-1, minorTopVer=0],
> err=null, skipPrepare=false
> class org.apache.ignite.binary.BinaryInvalidTypeException:
> SQL_PUBLIC_T_a975cf68_1738_43ca_915b_a52e6b89c049_KEY
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:719)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1772)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1731)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:826)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:156)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:199)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinariesIfNeeded(CacheObjectUtils.java:126)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:205)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinaryIfNeeded(CacheObjectUtils.java:78)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:138)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1795)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1782)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.completeFuture(GridNearAtomicAbstractUpdateFuture.java:353)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.onPrimaryResponse(GridNearAtomicUpdateFuture.java:467)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateResponse(GridDhtAtomicCache.java:3207)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$500(GridDhtAtomicCache.java:143)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:303)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:298)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1151)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:592)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:393)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:110)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:309)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1909)
> at
>
[jira] [Commented] (IGNITE-16397) Calcite engine. Failed to insert to table with two or more columns in primary keys
[
https://issues.apache.org/jira/browse/IGNITE-16397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488739#comment-17488739
]
Aleksey Plekhanov commented on IGNITE-16397:
[~ivandasch], thanks for the review! Merged to sql-calcite branch.
> Calcite engine. Failed to insert to table with two or more columns in primary
> keys
> --
>
> Key: IGNITE-16397
> URL: https://issues.apache.org/jira/browse/IGNITE-16397
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, calcite3-required
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For example:
> {noformat}
> CREATE TABLE t(id INT, val VARCHAR, PRIMARY KEY(id, val));
> INSERT INTO t(id, val) VALUES (1, 'a');
> {noformat}
> Fails with:
> {noformat}
> Failed processing message [senderId=8aec0b77-e5a2-49b5-8f77-0f0a7771,
> msg=GridNearAtomicUpdateResponse
> [nodeId=235d7fbc-2a05-4d8b-8e37-3dff3980fc76, futId=1, errs=null,
> ret=GridCacheReturn [v=HashMap
> {SQL_PUBLIC_T_a975cf68_1738_43ca_915b_a52e6b89c049_KEY [idHash=1524322354,
> hash=-904731590, VAL=a, ID=1]=CacheInvokeResult [res=1, err=null]},
> cacheObj=null, success=false, invokeRes=true, loc=true, cacheId=-1578586257],
> remapTopVer=null, nearUpdates=null, partId=552, mapping=ArrayList [],
> nodeLeft=false, super=GridCacheIdMessage [cacheId=-1578586257,
> super=GridCacheMessage [msgId=30, depInfo=null,
> lastAffChangedTopVer=AffinityTopologyVersion [topVer=-1, minorTopVer=0],
> err=null, skipPrepare=false
> class org.apache.ignite.binary.BinaryInvalidTypeException:
> SQL_PUBLIC_T_a975cf68_1738_43ca_915b_a52e6b89c049_KEY
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:719)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1772)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1731)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:826)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:156)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:199)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinariesIfNeeded(CacheObjectUtils.java:126)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:205)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinaryIfNeeded(CacheObjectUtils.java:78)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:138)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1795)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1782)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.completeFuture(GridNearAtomicAbstractUpdateFuture.java:353)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.onPrimaryResponse(GridNearAtomicUpdateFuture.java:467)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateResponse(GridDhtAtomicCache.java:3207)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$500(GridDhtAtomicCache.java:143)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:303)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:298)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1151)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:592)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:393)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:110)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:309)
> at
>
[jira] [Updated] (IGNITE-16119) Caclite engine. Refactor IgniteBuiltInMethod and IgniteMethod classes
[
https://issues.apache.org/jira/browse/IGNITE-16119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16119:
---
Labels: calcite3-required (was: calcite2-required calcite3-required)
> Caclite engine. Refactor IgniteBuiltInMethod and IgniteMethod classes
> -
>
> Key: IGNITE-16119
> URL: https://issues.apache.org/jira/browse/IGNITE-16119
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite3-required
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Looks like {{IgniteBuiltInMethod}} and {{IgniteMethod}} classes have the same
> purpose. We should choose and leave one of them.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16119) Caclite engine. Refactor IgniteBuiltInMethod and IgniteMethod classes
[
https://issues.apache.org/jira/browse/IGNITE-16119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488734#comment-17488734
]
Aleksey Plekhanov commented on IGNITE-16119:
[~ivandasch], thanks for the review! Merged to sql-calcite branch.
> Caclite engine. Refactor IgniteBuiltInMethod and IgniteMethod classes
> -
>
> Key: IGNITE-16119
> URL: https://issues.apache.org/jira/browse/IGNITE-16119
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, calcite3-required
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Looks like {{IgniteBuiltInMethod}} and {{IgniteMethod}} classes have the same
> purpose. We should choose and leave one of them.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16119) Caclite engine. Refactor IgniteBuiltInMethod and IgniteMethod classes
[
https://issues.apache.org/jira/browse/IGNITE-16119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16119:
---
Labels: calcite calcite3-required (was: calcite3-required)
> Caclite engine. Refactor IgniteBuiltInMethod and IgniteMethod classes
> -
>
> Key: IGNITE-16119
> URL: https://issues.apache.org/jira/browse/IGNITE-16119
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, calcite3-required
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Looks like {{IgniteBuiltInMethod}} and {{IgniteMethod}} classes have the same
> purpose. We should choose and leave one of them.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16493) Calcite engine. Decorrelation after subquery rewrite
[
https://issues.apache.org/jira/browse/IGNITE-16493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16493:
---
Description:
Currently decorrelation is performed in {{SqlToRelConverter}}, but after this
{{PlannerPhase.HEP_DECORRELATE}} planning phase is executed (which actually
rewrites subqueries into correlates, but doesn't perform decorrelation). In
some cases, other types of join can cost less than correlated nested loop join,
so we can try to decorrelate the query plan again after
{{PlannerPhase.HEP_DECORRELATE}} phase (call
{{RelDecorrelator.decorrelateQuery}}).
{{PlannerPhase.HEP_DECORRELATE}} should be also renamed to something like
"HEP_REWRITE_SUBQUERY".
was:
Currently decorrelation is performed in {{SqlToRelConverter}}, but after this
{{PlannerPhase.HEP_DECORRELATE}} planning phase is executed (which actually
rewrites subqueries into correlates, but doesn't perform decorrelation). In
some cases, other types of join can cost less than correlated nested loop join,
so we can try to decorrelate this query again after
{{PlannerPhase.HEP_DECORRELATE}} phase (call
{{RelDecorrelator.decorrelateQuery}}).
{{PlannerPhase.HEP_DECORRELATE}} should be also renamed to something like
"HEP_REWRITE_SUBQUERY".
> Calcite engine. Decorrelation after subquery rewrite
>
>
> Key: IGNITE-16493
> URL: https://issues.apache.org/jira/browse/IGNITE-16493
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required
>
> Currently decorrelation is performed in {{SqlToRelConverter}}, but after this
> {{PlannerPhase.HEP_DECORRELATE}} planning phase is executed (which actually
> rewrites subqueries into correlates, but doesn't perform decorrelation). In
> some cases, other types of join can cost less than correlated nested loop
> join, so we can try to decorrelate the query plan again after
> {{PlannerPhase.HEP_DECORRELATE}} phase (call
> {{RelDecorrelator.decorrelateQuery}}).
> {{PlannerPhase.HEP_DECORRELATE}} should be also renamed to something like
> "HEP_REWRITE_SUBQUERY".
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16493) Calcite engine. Decorrelation after subquery rewrite
Aleksey Plekhanov created IGNITE-16493:
--
Summary: Calcite engine. Decorrelation after subquery rewrite
Key: IGNITE-16493
URL: https://issues.apache.org/jira/browse/IGNITE-16493
Project: Ignite
Issue Type: Improvement
Reporter: Aleksey Plekhanov
Currently decorrelation is performed in {{SqlToRelConverter}}, but after this
{{PlannerPhase.HEP_DECORRELATE}} planning phase is executed (which actually
rewrites subqueries into correlates, but doesn't perform decorrelation). In
some cases, other types of join can cost less than correlated nested loop join,
so we can try to decorrelate this query again after
{{PlannerPhase.HEP_DECORRELATE}} phase (call
{{RelDecorrelator.decorrelateQuery}}).
{{PlannerPhase.HEP_DECORRELATE}} should be also renamed to something like
"HEP_REWRITE_SUBQUERY".
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16397) Calcite engine. Failed to insert to table with two or more columns in primary keys
[
https://issues.apache.org/jira/browse/IGNITE-16397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-16397:
--
Assignee: Aleksey Plekhanov
> Calcite engine. Failed to insert to table with two or more columns in primary
> keys
> --
>
> Key: IGNITE-16397
> URL: https://issues.apache.org/jira/browse/IGNITE-16397
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, calcite3-required
>
> For example:
> {noformat}
> CREATE TABLE t(id INT, val VARCHAR, PRIMARY KEY(id, val));
> INSERT INTO t(id, val) VALUES (1, 'a');
> {noformat}
> Fails with:
> {noformat}
> Failed processing message [senderId=8aec0b77-e5a2-49b5-8f77-0f0a7771,
> msg=GridNearAtomicUpdateResponse
> [nodeId=235d7fbc-2a05-4d8b-8e37-3dff3980fc76, futId=1, errs=null,
> ret=GridCacheReturn [v=HashMap
> {SQL_PUBLIC_T_a975cf68_1738_43ca_915b_a52e6b89c049_KEY [idHash=1524322354,
> hash=-904731590, VAL=a, ID=1]=CacheInvokeResult [res=1, err=null]},
> cacheObj=null, success=false, invokeRes=true, loc=true, cacheId=-1578586257],
> remapTopVer=null, nearUpdates=null, partId=552, mapping=ArrayList [],
> nodeLeft=false, super=GridCacheIdMessage [cacheId=-1578586257,
> super=GridCacheMessage [msgId=30, depInfo=null,
> lastAffChangedTopVer=AffinityTopologyVersion [topVer=-1, minorTopVer=0],
> err=null, skipPrepare=false
> class org.apache.ignite.binary.BinaryInvalidTypeException:
> SQL_PUBLIC_T_a975cf68_1738_43ca_915b_a52e6b89c049_KEY
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:719)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1772)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1731)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:826)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:156)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:199)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinariesIfNeeded(CacheObjectUtils.java:126)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:205)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinaryIfNeeded(CacheObjectUtils.java:78)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:138)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1795)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1782)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.completeFuture(GridNearAtomicAbstractUpdateFuture.java:353)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.onPrimaryResponse(GridNearAtomicUpdateFuture.java:467)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateResponse(GridDhtAtomicCache.java:3207)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$500(GridDhtAtomicCache.java:143)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:303)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:298)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1151)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:592)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:393)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:110)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:309)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1909)
> at
>
[jira] [Assigned] (IGNITE-16119) Caclite engine. Refactor IgniteBuiltInMethod and IgniteMethod classes
[
https://issues.apache.org/jira/browse/IGNITE-16119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-16119:
--
Assignee: Aleksey Plekhanov
> Caclite engine. Refactor IgniteBuiltInMethod and IgniteMethod classes
> -
>
> Key: IGNITE-16119
> URL: https://issues.apache.org/jira/browse/IGNITE-16119
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, calcite3-required
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Looks like {{IgniteBuiltInMethod}} and {{IgniteMethod}} classes have the same
> purpose. We should choose and leave one of them.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16161) Memory leak in BaseQueryContext
[ https://issues.apache.org/jira/browse/IGNITE-16161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-16161: --- Labels: calcite3-required ignite-3 (was: calcite2-required calcite3-required ignite-3) > Memory leak in BaseQueryContext > --- > > Key: IGNITE-16161 > URL: https://issues.apache.org/jira/browse/IGNITE-16161 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0.0-alpha3 >Reporter: Vyacheslav Koptilin >Assignee: Andrey Mashenkov >Priority: Blocker > Labels: calcite3-required, ignite-3 > Fix For: 3.0.0-alpha4 > > Attachments: image-2021-12-20-14-37-02-163.png, image.png > > Time Spent: 40m > Remaining Estimate: 0h > > BaseQueryContext contains a number of static fields that are used in order to > store references to internal classes. For example, BaseQueryContext.CLUSTER > which indirectly refers to ignite tables (TableImpl instances). > Unfortunately, these references are not cleared even though the corresponding > ignite node is stopped. > The following trace based on a heap dump illustrates the issue: > !image-2021-12-20-14-37-02-163.png! > This issue can be partially mitigated by clearing ring buffers in > StripedDisruptor, but the right way to fix the issue is a proper approach to > handle static collections in BaseQueryContext. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (IGNITE-16414) Calcite engine. Sorted index spool produces wrong collation
[ https://issues.apache.org/jira/browse/IGNITE-16414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488105#comment-17488105 ] Aleksey Plekhanov edited comment on IGNITE-16414 at 2/7/22, 1:26 PM: - [~zstan], [~ivandasch] thanks for the review! Merged to sql-calcite branch. was (Author: alex_pl): [~zstan] thanks for the review! Merged to sql-calcite branch. > Calcite engine. Sorted index spool produces wrong collation > --- > > Key: IGNITE-16414 > URL: https://issues.apache.org/jira/browse/IGNITE-16414 > Project: Ignite > Issue Type: Bug >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: calcite3-required > Time Spent: 1h 10m > Remaining Estimate: 0h > > The sorted index spool does not take into account input collation directions > and null ordering. When generating collation based on conditions, default > direction and null ordering are used. This leads to wrong planning in case of > not default null ordering (additional sort node inserted even if we iterating > by index with required collation) and wrong index conditions usage in case of > descending direction (upper and lower bound are inverted for DESC direction). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16414) Calcite engine. Sorted index spool produces wrong collation
[ https://issues.apache.org/jira/browse/IGNITE-16414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-16414: --- Labels: calcite3-required (was: calcite2-required calcite3-required) > Calcite engine. Sorted index spool produces wrong collation > --- > > Key: IGNITE-16414 > URL: https://issues.apache.org/jira/browse/IGNITE-16414 > Project: Ignite > Issue Type: Bug >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: calcite3-required > Time Spent: 50m > Remaining Estimate: 0h > > The sorted index spool does not take into account input collation directions > and null ordering. When generating collation based on conditions, default > direction and null ordering are used. This leads to wrong planning in case of > not default null ordering (additional sort node inserted even if we iterating > by index with required collation) and wrong index conditions usage in case of > descending direction (upper and lower bound are inverted for DESC direction). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16414) Calcite engine. Sorted index spool produces wrong collation
[ https://issues.apache.org/jira/browse/IGNITE-16414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488105#comment-17488105 ] Aleksey Plekhanov commented on IGNITE-16414: [~zstan] thanks for the review! Merged to sql-calcite branch. > Calcite engine. Sorted index spool produces wrong collation > --- > > Key: IGNITE-16414 > URL: https://issues.apache.org/jira/browse/IGNITE-16414 > Project: Ignite > Issue Type: Bug >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: calcite2-required, calcite3-required > Time Spent: 50m > Remaining Estimate: 0h > > The sorted index spool does not take into account input collation directions > and null ordering. When generating collation based on conditions, default > direction and null ordering are used. This leads to wrong planning in case of > not default null ordering (additional sort node inserted even if we iterating > by index with required collation) and wrong index conditions usage in case of > descending direction (upper and lower bound are inverted for DESC direction). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16191) Calcite engine. Unexpected result of COUNT with multiple parameters
[
https://issues.apache.org/jira/browse/IGNITE-16191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16191:
---
Labels: calcite3-required (was: calcite2-required calcite3-required)
> Calcite engine. Unexpected result of COUNT with multiple parameters
> ---
>
> Key: IGNITE-16191
> URL: https://issues.apache.org/jira/browse/IGNITE-16191
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Aleksey Plekhanov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: calcite3-required
> Fix For: 2.13
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The calcite engine supports the {{COUNT}} aggregate function with multiple
> parameters. Such a function should return the number of input rows for which
> parameters are wholly not null.
> But currently queries like:
> {noformat}
> SELECT COUNT(null, 1)
> SELECT COUNT(1, null)
> {noformat}
> Return 0 (expected 1).
> Query:
> {noformat}
> SELECT COUNT(null, null)
> {noformat}
> Throw an exception:
> {noformat}
> Caused by: java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
> at java.util.ArrayList.rangeCheck(ArrayList.java:657)
> at java.util.ArrayList.get(ArrayList.java:433)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.agg.AccumulatorsFactory$WrapperPrototype$1.apply(AccumulatorsFactory.java:226)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.agg.AccumulatorsFactory$WrapperPrototype$1.apply(AccumulatorsFactory.java:223)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.agg.AccumulatorsFactory$AccumulatorWrapperImpl.add(AccumulatorsFactory.java:305)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.HashAggregateNode$Grouping.addOnMapper(HashAggregateNode.java:294)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.HashAggregateNode$Grouping.add(HashAggregateNode.java:265)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.HashAggregateNode$Grouping.access$100(HashAggregateNode.java:222)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.HashAggregateNode.push(HashAggregateNode.java:127)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.ScanNode.push(ScanNode.java:107)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16299) Calcite. Statement with explain can`t be parsed.
[
https://issues.apache.org/jira/browse/IGNITE-16299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16299:
---
Labels: calcite ignite-3 (was: calcite calcite2-required calcite3-required
ignite-3)
> Calcite. Statement with explain can`t be parsed.
>
>
> Key: IGNITE-16299
> URL: https://issues.apache.org/jira/browse/IGNITE-16299
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: calcite, ignite-3
>
> Code below throws exception:
> {code:java}
> executeSql("CREATE TABLE test(i INTEGER)");
> executeSql("INSERT INTO test VALUES (1), (2)");
> assertQuery("explain plan for SELECT (SELECT i FROM test EXCEPT
> SELECT test.i) FROM test")
> .returns(1)
> .returns(2)
> .check();
> {code}
> {code:java}
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed
> to parse query.
> at
> org.apache.ignite.internal.processors.query.calcite.util.Commons.parse(Commons.java:207)
> at
> org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.query(CalciteQueryProcessor.java:341)
> at
> org.apache.ignite.internal.processors.query.calcite.QueryChecker.check(QueryChecker.java:349)
> at
> org.apache.ignite.internal.processors.query.calcite.integration.SetOpIntegrationTest.testSetOpRewindability(SetOpIntegrationTest.java:433)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2432)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.apache.calcite.sql.parser.SqlParseException: Encountered "" at
> line 1, column 18.
> Was expecting one of:
>
> at
> org.apache.ignite.internal.processors.query.calcite.sql.IgniteSqlParserImpl.convertException(IgniteSqlParserImpl.java:397)
> at
> org.apache.ignite.internal.processors.query.calcite.sql.IgniteSqlParserImpl.normalizeException(IgniteSqlParserImpl.java:161)
> at
> org.apache.calcite.sql.parser.SqlParser.handleException(SqlParser.java:145)
> at
> org.apache.calcite.sql.parser.SqlParser.parseStmtList(SqlParser.java:200)
> at
> org.apache.ignite.internal.processors.query.calcite.util.Commons.parse(Commons.java:222)
> at
> org.apache.ignite.internal.processors.query.calcite.util.Commons.parse(Commons.java:204)
> ... 13 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-13971) Merge Calcite SQL engine to Ignite 3.0
[ https://issues.apache.org/jira/browse/IGNITE-13971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-13971: --- Labels: calcite ignite-3 (was: ignite-3) > Merge Calcite SQL engine to Ignite 3.0 > -- > > Key: IGNITE-13971 > URL: https://issues.apache.org/jira/browse/IGNITE-13971 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Konstantin Orlov >Priority: Major > Labels: calcite, ignite-3 > > The main goal is start development on a ticket-based approach when we could > merge each new ticket to master separately, instead of integration branch > approach. Also, the new engine will be integrated and available for users to > start using and testing it. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-13971) Merge Calcite SQL engine to Ignite 3.0
[ https://issues.apache.org/jira/browse/IGNITE-13971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-13971: --- Labels: ignite-3 (was: calcite2-required calcite3-required ignite-3) > Merge Calcite SQL engine to Ignite 3.0 > -- > > Key: IGNITE-13971 > URL: https://issues.apache.org/jira/browse/IGNITE-13971 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > The main goal is start development on a ticket-based approach when we could > merge each new ticket to master separately, instead of integration branch > approach. Also, the new engine will be integrated and available for users to > start using and testing it. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-13797) Calcite bug. CREATE TABLE with WHERE SELECT 1;
[
https://issues.apache.org/jira/browse/IGNITE-13797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-13797:
---
Labels: calcite (was: calcite calcite2-required calcite3-required)
> Calcite bug. CREATE TABLE with WHERE SELECT 1;
> --
>
> Key: IGNITE-13797
> URL: https://issues.apache.org/jira/browse/IGNITE-13797
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Evgeny Stanilovsky
>Assignee: Ivan Daschinsky
>Priority: Major
> Labels: calcite
>
> CREATE TABLE TABLE_E061_09_01_04 ( A INT PRIMARY KEY, CC INTEGER ); SELECT A
> FROM TABLE_E061_09_01_04 WHERE A = ( SELECT 1 );
> fires:
> {noformat}
> java.lang.AssertionError: RelSubset
> [rel#4121:RelSubset#7.IGNITE.[].single.rewindable.uncorrelated] has wrong
> best cost 1021.13999. Correct cost is 1057.0
> at org.apache.calcite.util.Litmus$1.fail(Litmus.java:31)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.isValid(VolcanoPlanner.java:647)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:610)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.transformTo(VolcanoRuleCall.java:148)
> at
> org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:268)
> at
> org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:283)
> at
> org.apache.calcite.rel.convert.ConverterRule.onMatch(ConverterRule.java:169)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:229)
> at
> org.apache.calcite.plan.volcano.TopDownRuleDriver.applyGenerator(TopDownRuleDriver.java:142)
> at
> org.apache.calcite.plan.volcano.TopDownRuleDriver.access$600(TopDownRuleDriver.java:47)
> at
> org.apache.calcite.plan.volcano.TopDownRuleDriver$ApplyRule.perform(TopDownRuleDriver.java:519)
> at
> org.apache.calcite.plan.volcano.TopDownRuleDriver.drive(TopDownRuleDriver.java:101)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:510)
> at
> org.apache.calcite.tools.Programs$RuleSetProgram.run(Programs.java:312)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.IgnitePlanner.transform(IgnitePlanner.java:258)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.optimize(ExecutionServiceImpl.java:616)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareQuery(ExecutionServiceImpl.java:568)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareSingle(ExecutionServiceImpl.java:542)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareQuery(ExecutionServiceImpl.java:501)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.QueryPlanCacheImpl.queryPlan(QueryPlanCacheImpl.java:84)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executeQuery(ExecutionServiceImpl.java:378)
> at
> org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.query(CalciteQueryProcessor.java:240)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2787)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2743)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-14531) Calcite improvements. Support DISTINCT for aggregates call at the execution
[
https://issues.apache.org/jira/browse/IGNITE-14531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-14531:
---
Labels: calcite (was: calcite2-required calcite3-required)
> Calcite improvements. Support DISTINCT for aggregates call at the execution
> ---
>
> Key: IGNITE-14531
> URL: https://issues.apache.org/jira/browse/IGNITE-14531
> Project: Ignite
> Issue Type: Improvement
>Reporter: Taras Ledkov
>Priority: Major
> Labels: calcite
>
> Now {{Accumulators#accumulatorFactory}} and all implementation of the
> {{Accumulator}} doesn't support DISTINCT (see {{AggregateCall#isDistinct}}).
> Must be implemented.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-14537) Calcite engine. Nested arbitrary queries hangs on optimizing
[
https://issues.apache.org/jira/browse/IGNITE-14537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-14537:
---
Labels: calcite (was: calcite2-required calcite3-required)
> Calcite engine. Nested arbitrary queries hangs on optimizing
> --
>
> Key: IGNITE-14537
> URL: https://issues.apache.org/jira/browse/IGNITE-14537
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Taras Ledkov
>Priority: Major
> Labels: calcite
>
> The query with nested arbitrary subqueries aren't planned.
> Test: {{subquery/test_neumann.test_ignore}}
> See more: [Unnesting Arbitrary
> Queries|https://subs.emis.de/LNI/Proceedings/Proceedings241/383.pdf]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-14681) Calcite engine. Extend return type of sum() aggregate function
[
https://issues.apache.org/jira/browse/IGNITE-14681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-14681:
---
Labels: calcite3-required ignite-3 (was: calcite2-required
calcite3-required ignite-3)
> Calcite engine. Extend return type of sum() aggregate function
> --
>
> Key: IGNITE-14681
> URL: https://issues.apache.org/jira/browse/IGNITE-14681
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Aleksey Plekhanov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: calcite3-required, ignite-3
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Currently, {{sum()}} aggregate function returns the same type as an argument
> and there can be an overflow.
> For example, query:
> {noformat}
> SELECT SUM(i::SMALLINT) FROM (SELECT 32000 as i UNION ALL SELECT
> 32000){noformat}
> Returns {{-1536}}.
> or
> {noformat}
> CREATE TABLE integers(i INTEGER);
> INSERT INTO integers SELECT * FROM table(system_range(0, 999, 1));
> SELECT SUM(b) FROM bigints
> {noformat}
> Returns {{499500}} instead of {{4611686018427388403500}}.
> Perhaps it would be better to return an extended type as some other vendors
> do.
> For example, PostgreSQL returns {{bigint}} for {{smallint}} or {{int}}
> arguments, {{numeric}} for {{bigint}} arguments, {{double precision}} for
> floating-point arguments. MySQL returns a {{DECIMAL}} value for exact-value
> arguments ({{INTEGER}} or {{DECIMAL}}), and a {{DOUBLE}} value for
> approximate-value arguments ({{FLOAT}} or {{DOUBLE}})
> Affected tests:
> {{modules/calcite/src/test/sql/aggregate/aggregates/test_sum.test_ignore}}
> Result type of SUM:
> || Argument type || SUM type ||
> | TINYINT
> SMALLINT
> INTEGER | BIGINT |
> | REAL
> FLOAT
> DOUBLE | DOUBLE |
> | BIGINT
> DECIMAL | DECIMAL |
> | other *type* | the same *type* |
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-14862) Calcite improvements. Collect all metadata information
[ https://issues.apache.org/jira/browse/IGNITE-14862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-14862: --- Labels: calcite sql (was: calcite2-required calcite3-required sql) > Calcite improvements. Collect all metadata information > -- > > Key: IGNITE-14862 > URL: https://issues.apache.org/jira/browse/IGNITE-14862 > Project: Ignite > Issue Type: New Feature >Reporter: Yury Gerzhedovich >Priority: Major > Labels: calcite, sql > > We need to collect all metadata information to provide it at least for API > (thin drivers, public API, ...) and for VIEWS. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-14713) Calcite. Explain failed for subquery expression.
[
https://issues.apache.org/jira/browse/IGNITE-14713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-14713:
---
Labels: calcite (was: calcite calcite2-required calcite3-required)
> Calcite. Explain failed for subquery expression.
>
>
> Key: IGNITE-14713
> URL: https://issues.apache.org/jira/browse/IGNITE-14713
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeny Stanilovsky
>Assignee: Ivan Daschinsky
>Priority: Major
> Labels: calcite
>
> Failure test:
> {code:java}
>@Test
> public void test0() throws Exception {
> IgniteCache cache = grid(0).getOrCreateCache(
> new CacheConfiguration("test")
> .setBackups(1)
> .setIndexedTypes(Integer.class, Integer.class)
> );
> for (int i = 0; i < 100; i++)
> cache.put(i, i);
> awaitPartitionMapExchange();
> // Correlated INNER join.
> checkQuery("explain plan for SELECT t._val FROM \"test\".Integer t
> WHERE t._val < 5 AND " +
> "t._key in (SELECT x FROM table(system_range(t._val, t._val))) ")
> .check();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-14866) Calcite. Check SQL function works
[ https://issues.apache.org/jira/browse/IGNITE-14866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-14866: --- Labels: calcite3-required (was: calcite2-required calcite3-required) > Calcite. Check SQL function works > - > > Key: IGNITE-14866 > URL: https://issues.apache.org/jira/browse/IGNITE-14866 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: calcite3-required > Time Spent: 1h 40m > Remaining Estimate: 0h > > We need to write tests on existing simple SQL functions (nor aggregation or > window functions) and have a list of supported functions. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-14953) Calcite. Sort out test scripts 'function'
[
https://issues.apache.org/jira/browse/IGNITE-14953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-14953:
---
Labels: calcite3-required (was: calcite2-required calcite3-required)
> Calcite. Sort out test scripts 'function'
> -
>
> Key: IGNITE-14953
> URL: https://issues.apache.org/jira/browse/IGNITE-14953
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: calcite3-required
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> We have a bunch of unsorted tests included in ScriptRunnerTestSuite. As
> result, we should have to mute all failed tests, file a ticket for related
> problems and have a green run for the suite.
> Scripts dir: {{function}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15323) Calcite engine. Query lifecycle refactoting
[
https://issues.apache.org/jira/browse/IGNITE-15323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-15323:
---
Labels: calcite (was: calcite2-required calcite3-required)
> Calcite engine. Query lifecycle refactoting
> ---
>
> Key: IGNITE-15323
> URL: https://issues.apache.org/jira/browse/IGNITE-15323
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: calcite
>
> Motivation and goals:
> - introduce a {{Query}} abstraction to track a query on all phases: planning,
> mapping, execution;
> - use one place to query management
> - try to make query phases more isolated, e.g.. now {{PlanningContext}}
> contains AffinityTopologyVersion and node IDs. It looks like this information
> has nothing to do with the query planning.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15110) Calcite bug. Function CHAR_LENGTH works incorrect with UNICODE
[
https://issues.apache.org/jira/browse/IGNITE-15110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-15110:
---
Labels: calcite (was: calcite2-required calcite3-required)
> Calcite bug. Function CHAR_LENGTH works incorrect with UNICODE
> --
>
> Key: IGNITE-15110
> URL: https://issues.apache.org/jira/browse/IGNITE-15110
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
> Labels: calcite
>
> Function CHAR_LENGTH returns an incorrect results for unicode symbols. E.g
> for below query returns 2 instead of 1
> {code:sql}
> SELECT char_length('閭'){code}
> see src/test/sql/function/string/test_char_length.test_ignore
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15539) Calcite. Unexpected resultset from aggregate query.
[
https://issues.apache.org/jira/browse/IGNITE-15539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-15539:
---
Labels: calcite (was: calcite2-required calcite3-required ignite-3)
> Calcite. Unexpected resultset from aggregate query.
> ---
>
> Key: IGNITE-15539
> URL: https://issues.apache.org/jira/browse/IGNITE-15539
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: calcite
>
> In terms of SqlScriptRunner:
> {noformat}
> statement ok
> CREATE TABLE test (a INTEGER, b INTEGER);
> statement ok
> INSERT INTO test VALUES (11, 22), (13, 22), (12, 21)
> query IR
> SELECT test.b, SUM(a) FROM test GROUP BY b ORDER BY COUNT(a) DESC;
>
> 2148.00
> 2224.00
> {noformat}
> {noformat}
> /sql/aggregate/group/test_group_by.test[_ignore]
> /sql/types/null/test_null_aggr.test[_ignore]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15540) Calcite engine. Support for QUANTILE, MEDIAN aggregate functions.
[
https://issues.apache.org/jira/browse/IGNITE-15540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-15540:
---
Labels: calcite (was: calcite2-required calcite3-required ignite-3)
> Calcite engine. Support for QUANTILE, MEDIAN aggregate functions.
> -
>
> Key: IGNITE-15540
> URL: https://issues.apache.org/jira/browse/IGNITE-15540
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: calcite
>
> Tests:
> {noformat}
> aggregate/aggregates/test_quantile.test_ignore
> aggregate/aggregates/test_quantile_list.test_ignore
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15808) Calcite engine. Failed to join table with itself with 'USING' clause
[
https://issues.apache.org/jira/browse/IGNITE-15808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-15808:
---
Labels: calcite (was: calcite calcite2-required calcite3-required)
> Calcite engine. Failed to join table with itself with 'USING' clause
>
>
> Key: IGNITE-15808
> URL: https://issues.apache.org/jira/browse/IGNITE-15808
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Priority: Major
> Labels: calcite
>
> Statement:
> {noformat}
> CREATE TABLE test (t INT);
> SELECT * FROM test t1 JOIN test t2 USING (t){noformat}
> Failed with:
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: 2
> {noformat}
> But statement:
> {noformat}
> CREATE TABLE test (t INT);
> CREATE TABLE test2 (t INT);
> SELECT * FROM test t1 JOIN test2 t2 USING (t){noformat}
> Works.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16130) Calcite. Natural join returns empty resultset.
[
https://issues.apache.org/jira/browse/IGNITE-16130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16130:
---
Labels: calcite (was: calcite calcite2-required calcite3-required ignite-3)
> Calcite. Natural join returns empty resultset.
> --
>
> Key: IGNITE-16130
> URL: https://issues.apache.org/jira/browse/IGNITE-16130
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: calcite
>
> {noformat}
> statement ok
> CREATE TABLE t1(a INTEGER, b INTEGER, c INTEGER);
> statement ok
> CREATE TABLE t2(b INTEGER, c INTEGER, d INTEGER);
> statement ok
> INSERT INTO t1 VALUES(1,2,3);
> statement ok
> INSERT INTO t1 VALUES(2,3,4);
> statement ok
> INSERT INTO t1 VALUES(3,4,5);
> statement ok
> INSERT INTO t2 VALUES(1,2,3);
> statement ok
> INSERT INTO t2 VALUES(2,3,4);
> statement ok
> INSERT INTO t2 VALUES(3,4,5);
> query III rowsort
> SELECT t2.* FROM t2 NATURAL JOIN t1;
>
> 2 3 4
> 3 4 5
> query III rowsort
> SELECT t1.* FROM t2 NATURAL JOIN t1;
>
> 1 2 3
> 2 3 4
> query II nosort
> SELECT t1.*, t2.* FROM t2 NATURAL JOIN t1 ORDER BY t1.a
>
> 1 2 3 2 3 4
> 2 3 4 3 4 5
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16142) Calcite. Append additional JOIN and ORDER BY functionality covering tests.
[ https://issues.apache.org/jira/browse/IGNITE-16142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-16142: --- Labels: calcite calcite3-required ignite-3 (was: calcite calcite2-required calcite3-required ignite-3) > Calcite. Append additional JOIN and ORDER BY functionality covering tests. > -- > > Key: IGNITE-16142 > URL: https://issues.apache.org/jira/browse/IGNITE-16142 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Evgeny Stanilovsky >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: calcite, calcite3-required, ignite-3 > Time Spent: 0.5h > Remaining Estimate: 0h > > In case of calcite engine test coverage increasing, we need to append > additional JOIN and ORDER BY tests. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16460) Calcite. Fix Calcite TC test suite.
[
https://issues.apache.org/jira/browse/IGNITE-16460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16460:
---
Labels: calcite (was: calcite2-required)
> Calcite. Fix Calcite TC test suite.
> ---
>
> Key: IGNITE-16460
> URL: https://issues.apache.org/jira/browse/IGNITE-16460
> Project: Ignite
> Issue Type: Test
> Components: build, sql
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: calcite
> Fix For: 2.13
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Calcite TC suite fails with
> {code:java}
> [11:29:20]Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test (default-cli) on
> project ignite-calcite: Execution default-cli of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed:
> org.apache.ignite.tools.surefire.TestSuiteAwareTestsetReporter
> {code}
> Let's fix it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-15993) Calcite engine. Wrong result for single-value aggregation from empty source
[
https://issues.apache.org/jira/browse/IGNITE-15993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488037#comment-17488037
]
Aleksey Plekhanov commented on IGNITE-15993:
Calcite version was updated, I've uncommented tests, now they are green,
[~vladsz83] can you please review?
> Calcite engine. Wrong result for single-value aggregation from empty source
> ---
>
> Key: IGNITE-15993
> URL: https://issues.apache.org/jira/browse/IGNITE-15993
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Vladimir Steshin
>Priority: Minor
> Labels: calcite2-required, calcite3-required
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For example:
> {noformat}
> SELECT (SELECT 1 FROM (SELECT 1) WHERE 1 = 0)
> {noformat}
> Returns 0, but expected {{{}NULL{}}}.
> With correlated queries result even more strange:
> {noformat}
> CREATE TABLE test (a INTEGER)
> INSERT INTO test VALUES (1), (2), (null)
> SELECT (SELECT 1 FROM test t WHERE a = test.a) FROM test
> {noformat}
> Returns 1, 1, 1 (expected 1, 1, NULL)
> Related test {{test_correlated_subquery.test_ignore}}
> From SQL standard:
> {noformat}
> Let SS be a .
> Case:
> a) If the cardinality of SS is greater than 1 (one), then an exception
> condition is raised: cardinality violation.
> b) If the cardinality of SS is 0 (zero), then the value of the subquery> is the null value.
> c) Otherwise, let C be the column of simply contained in
> SS. The value of SS is the value of C in the unique row of the result of the
> .{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16414) Calcite engine. Sorted index spool produces wrong collation
[ https://issues.apache.org/jira/browse/IGNITE-16414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17487071#comment-17487071 ] Aleksey Plekhanov commented on IGNITE-16414: [~zstan], [~tledkov-gridgain], [~ivandasch], [~korlov], can you please review the patch? > Calcite engine. Sorted index spool produces wrong collation > --- > > Key: IGNITE-16414 > URL: https://issues.apache.org/jira/browse/IGNITE-16414 > Project: Ignite > Issue Type: Bug >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: calcite2-required, calcite3-required > Time Spent: 10m > Remaining Estimate: 0h > > The sorted index spool does not take into account input collation directions > and null ordering. When generating collation based on conditions, default > direction and null ordering are used. This leads to wrong planning in case of > not default null ordering (additional sort node inserted even if we iterating > by index with required collation) and wrong index conditions usage in case of > descending direction (upper and lower bound are inverted for DESC direction). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16443) Calcite engine. Incorrect nulls in search row processing by hash/sorted spools
[
https://issues.apache.org/jira/browse/IGNITE-16443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17487066#comment-17487066
]
Aleksey Plekhanov commented on IGNITE-16443:
[~ivandasch], [~tledkov-gridgain], thanks for the review!
Merged to sql-calcite branch.
> Calcite engine. Incorrect nulls in search row processing by hash/sorted spools
> --
>
> Key: IGNITE-16443
> URL: https://issues.apache.org/jira/browse/IGNITE-16443
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, calcite3-required
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently, the sorted spool comparator treats nulls in the search row as
> regular values and applies nulls ordering to them, but these nulls have
> another meaning: it means that any value matches the bound.
> For example, if we have the condition for spool {{a > 0}} it will be
> transformed to bounds: {{lower [0]}}, {{upper [null]}}, after comparing rows
> with lower bound we will get the correct result, but comparing with upper
> bound always give us {{1}} (value > null) with {{nulls first}} collation and
> no rows will be returned by index spool.
> For hash spool there is the reverse problem, we should not find rows if nulls
> are present in the search row, since condition NULL=NULL should not satisfy
> the filter in SQL.
> For index scan, there are no problems that lead to data inconsistency, but in
> the case of nulls in the search row, any value matches the bound and index
> scan becomes very ineffective. For example, if we have the index by field
> {{a}} and filter {{a = $cor0.b}}, for {{$cor0.b = null}} there will be the
> full index scan, all rows will be passed to the predicate and 0 rows will be
> produced after the predicate.
> Another problem with comparators: there is a dead code in
> {{ExpressionFactoryImpl#comparator(RelFieldCollation)}} which compare object
> by hash or bytes:
> * This code never executes since we support now only comparable types by
> Calcite-based SQL engine
> * Depends on H2
> * Serialize object by standard java serialization
> * Works only for ASC ordering
> * Works for sort/spool/sort aggregate nodes, but doesn't work for merge join
> I think we can get rid of this code at least until we don't support Object
> types and revert corresponding changes to ignite-indexing to avoid merge
> conflicts.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16443) Calcite engine. Incorrect nulls in search row processing by hash/sorted spools
[
https://issues.apache.org/jira/browse/IGNITE-16443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16443:
---
Labels: calcite3-required (was: calcite2-required calcite3-required)
> Calcite engine. Incorrect nulls in search row processing by hash/sorted spools
> --
>
> Key: IGNITE-16443
> URL: https://issues.apache.org/jira/browse/IGNITE-16443
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite3-required
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently, the sorted spool comparator treats nulls in the search row as
> regular values and applies nulls ordering to them, but these nulls have
> another meaning: it means that any value matches the bound.
> For example, if we have the condition for spool {{a > 0}} it will be
> transformed to bounds: {{lower [0]}}, {{upper [null]}}, after comparing rows
> with lower bound we will get the correct result, but comparing with upper
> bound always give us {{1}} (value > null) with {{nulls first}} collation and
> no rows will be returned by index spool.
> For hash spool there is the reverse problem, we should not find rows if nulls
> are present in the search row, since condition NULL=NULL should not satisfy
> the filter in SQL.
> For index scan, there are no problems that lead to data inconsistency, but in
> the case of nulls in the search row, any value matches the bound and index
> scan becomes very ineffective. For example, if we have the index by field
> {{a}} and filter {{a = $cor0.b}}, for {{$cor0.b = null}} there will be the
> full index scan, all rows will be passed to the predicate and 0 rows will be
> produced after the predicate.
> Another problem with comparators: there is a dead code in
> {{ExpressionFactoryImpl#comparator(RelFieldCollation)}} which compare object
> by hash or bytes:
> * This code never executes since we support now only comparable types by
> Calcite-based SQL engine
> * Depends on H2
> * Serialize object by standard java serialization
> * Works only for ASC ordering
> * Works for sort/spool/sort aggregate nodes, but doesn't work for merge join
> I think we can get rid of this code at least until we don't support Object
> types and revert corresponding changes to ignite-indexing to avoid merge
> conflicts.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16443) Calcite engine. Incorrect nulls in search row processing by hash/sorted spools
[
https://issues.apache.org/jira/browse/IGNITE-16443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486276#comment-17486276
]
Aleksey Plekhanov commented on IGNITE-16443:
[~zstan], [~ivandasch], [~tledkov-gridgain], can you please review the patch?
> Calcite engine. Incorrect nulls in search row processing by hash/sorted spools
> --
>
> Key: IGNITE-16443
> URL: https://issues.apache.org/jira/browse/IGNITE-16443
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, calcite3-required
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, the sorted spool comparator treats nulls in the search row as
> regular values and applies nulls ordering to them, but these nulls have
> another meaning: it means that any value matches the bound.
> For example, if we have the condition for spool {{a > 0}} it will be
> transformed to bounds: {{lower [0]}}, {{upper [null]}}, after comparing rows
> with lower bound we will get the correct result, but comparing with upper
> bound always give us {{1}} (value > null) with {{nulls first}} collation and
> no rows will be returned by index spool.
> For hash spool there is the reverse problem, we should not find rows if nulls
> are present in the search row, since condition NULL=NULL should not satisfy
> the filter in SQL.
> For index scan, there are no problems that lead to data inconsistency, but in
> the case of nulls in the search row, any value matches the bound and index
> scan becomes very ineffective. For example, if we have the index by field
> {{a}} and filter {{a = $cor0.b}}, for {{$cor0.b = null}} there will be the
> full index scan, all rows will be passed to the predicate and 0 rows will be
> produced after the predicate.
> Another problem with comparators: there is a dead code in
> {{ExpressionFactoryImpl#comparator(RelFieldCollation)}} which compare object
> by hash or bytes:
> * This code never executes since we support now only comparable types by
> Calcite-based SQL engine
> * Depends on H2
> * Serialize object by standard java serialization
> * Works only for ASC ordering
> * Works for sort/spool/sort aggregate nodes, but doesn't work for merge join
> I think we can get rid of this code at least until we don't support Object
> types and revert corresponding changes to ignite-indexing to avoid merge
> conflicts.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16315) Calcite engine. Query start request contains a lot of data
[
https://issues.apache.org/jira/browse/IGNITE-16315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486267#comment-17486267
]
Aleksey Plekhanov commented on IGNITE-16315:
[~zstan], thanks for the review!
Merged to sql-calcite branch.
> Calcite engine. Query start request contains a lot of data
> --
>
> Key: IGNITE-16315
> URL: https://issues.apache.org/jira/browse/IGNITE-16315
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, calcite3-required
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
> For simple queries SQL engine most of the time spend in writing/reading query
> start requests, which contains a lot of data. Nested instances of
> {{ColocationGroup}} class contain assignments for each partition
> ({{{}List>{}}}). Transferred size can be reduced if we compact
> assignments somehow. The target colocation group from fragment description
> contains redundant synthetic partitions, this also can be optimized.
> Messages workflow is not optimal too. First, we send {{QueryStartRequest}} to
> the remote nodes, remotes reply with the QueryStartResponse messages. After
> that remotes send batches with data to the target nodes and receive acks for
> each batch (acks required to limit inbox workload). When query execution is
> finished, the node initiator sends {{QueryCloseMessage}} to the remote nodes,
> remotes close queries, and sends back {{ErrorMessage}} to the initiator with
> the {{ExecutionCancelledException}} error (which is ignored on the initiator
> node).
> Also, some other optimizations are possible. Proposed changes:
> * Implement compaction of assignments of {{ColocationGroup}}
> * Reduce target colocation group partitions count
> * Fix caching of query plans (store original SQL as key, not parsed SQL, to
> avoid redundant parsing)
> * Change messages workflow (don't send ack messages for the last batch since
> it is redundant, self-close remote queries, and don't send close query
> messages to remote nodes, if we know for sure that it's already self-closed,
> don't send query start response if we already have sent batch for the same
> fragment before)
> * Reduce count of {{RexBuilder}} creation on the execution phase (RexBuilder
> is stateless and can be used one static instance)
> * Reduce count of Calcite types creation on the execution phase
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16315) Calcite engine. Query start request contains a lot of data
[
https://issues.apache.org/jira/browse/IGNITE-16315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16315:
---
Labels: calcite3-required (was: calcite2-required calcite3-required)
> Calcite engine. Query start request contains a lot of data
> --
>
> Key: IGNITE-16315
> URL: https://issues.apache.org/jira/browse/IGNITE-16315
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite3-required
> Time Spent: 5h 50m
> Remaining Estimate: 0h
>
> For simple queries SQL engine most of the time spend in writing/reading query
> start requests, which contains a lot of data. Nested instances of
> {{ColocationGroup}} class contain assignments for each partition
> ({{{}List>{}}}). Transferred size can be reduced if we compact
> assignments somehow. The target colocation group from fragment description
> contains redundant synthetic partitions, this also can be optimized.
> Messages workflow is not optimal too. First, we send {{QueryStartRequest}} to
> the remote nodes, remotes reply with the QueryStartResponse messages. After
> that remotes send batches with data to the target nodes and receive acks for
> each batch (acks required to limit inbox workload). When query execution is
> finished, the node initiator sends {{QueryCloseMessage}} to the remote nodes,
> remotes close queries, and sends back {{ErrorMessage}} to the initiator with
> the {{ExecutionCancelledException}} error (which is ignored on the initiator
> node).
> Also, some other optimizations are possible. Proposed changes:
> * Implement compaction of assignments of {{ColocationGroup}}
> * Reduce target colocation group partitions count
> * Fix caching of query plans (store original SQL as key, not parsed SQL, to
> avoid redundant parsing)
> * Change messages workflow (don't send ack messages for the last batch since
> it is redundant, self-close remote queries, and don't send close query
> messages to remote nodes, if we know for sure that it's already self-closed,
> don't send query start response if we already have sent batch for the same
> fragment before)
> * Reduce count of {{RexBuilder}} creation on the execution phase (RexBuilder
> is stateless and can be used one static instance)
> * Reduce count of Calcite types creation on the execution phase
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16354) Calcite engine. Memory leak in RelOptCluster during mapping
[
https://issues.apache.org/jira/browse/IGNITE-16354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16354:
---
Labels: calcite3-required (was: calcite2-required calcite3-required)
> Calcite engine. Memory leak in RelOptCluster during mapping
> ---
>
> Key: IGNITE-16354
> URL: https://issues.apache.org/jira/browse/IGNITE-16354
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite3-required
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> The static instance of {{RelOptCluster}} accumulates data in the cache
> (\{{BaseQueryContext.CLUSTER.mq.map}}) and never clear it. We should attach
> the new cluster query fragments during each mapping and detach it before
> storing the query plan in the query plan cache.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16443) Calcite engine. Incorrect nulls in search row processing by hash/sorted spools
[
https://issues.apache.org/jira/browse/IGNITE-16443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16443:
---
Description:
Currently, the sorted spool comparator treats nulls in the search row as
regular values and applies nulls ordering to them, but these nulls have another
meaning: it means that any value matches the bound.
For example, if we have the condition for spool {{a > 0}} it will be
transformed to bounds: {{lower [0]}}, {{upper [null]}}, after comparing rows
with lower bound we will get the correct result, but comparing with upper bound
always give us {{1}} (value > null) with {{nulls first}} collation and no rows
will be returned by index spool.
For hash spool there is the reverse problem, we should not find rows if nulls
are present in the search row, since condition NULL=NULL should not satisfy the
filter in SQL.
For index scan, there are no problems that lead to data inconsistency, but in
the case of nulls in the search row, any value matches the bound and index scan
becomes very ineffective. For example, if we have the index by field {{a}} and
filter {{a = $cor0.b}}, for {{$cor0.b = null}} there will be the full index
scan, all rows will be passed to the predicate and 0 rows will be produced
after the predicate.
Another problem with comparators: there is a dead code in
{{ExpressionFactoryImpl#comparator(RelFieldCollation)}} which compare object by
hash or bytes:
* This code never executes since we support now only comparable types by
Calcite-based SQL engine
* Depends on H2
* Serialize object by standard java serialization
* Works only for ASC ordering
* Works for sort/spool/sort aggregate nodes, but doesn't work for merge join
I think we can get rid of this code at least until we don't support Object
types and revert corresponding changes to ignite-indexing to avoid merge
conflicts.
was:
Currently, the sorted spool comparator treats nulls in the search row as
regular values and applies nulls ordering to them, but these nulls have another
meaning: it means that any value matches the bound.
For example, if we have the condition for spool {{a > 0}} it will be
transformed to bounds: {{{}lower [0]{}}}, {{{}upper [null]{}}}, after comparing
rows with lower bound we will get the correct result, but comparing with upper
bound always give us {{1}} (value > null) with {{nulls first}} collation and no
rows will be returned by index spool.
For hash spool there is the reverse problem, we should not find rows if nulls
are present in the search row, since condition NULL=NULL should not satisfy the
filter in SQL.
For index scan, there are no problems that lead to data inconsistency, but in
the case of nulls in the search row, any value matches the bound and index scan
becomes very ineffective. For example, if we have the index by field {{a}} and
filter {{{}a = $cor0.b{}}}, for {{$cor0.b = null }}there will be the full index
scan, all rows will be passed to the predicate and 0 rows will be produced
after the predicate.
Another problem with comparators: there is a dead code in
{{ExpressionFactoryImpl#comparator(RelFieldCollation)}} which compare object by
hash or bytes:
* This code never executes since we support now only comparable types by
Calcite-based SQL engine
* Depends on H2
* Serialize object by standard java serialization
* Works only for ASC ordering
* Works for sort/spool/sort aggregate nodes, but doesn't work for merge join
I think we can get rid of this code at least until we don't support Object
types and revert corresponding changes to ignite-indexing to avoid merge
conflicts.
> Calcite engine. Incorrect nulls in search row processing by hash/sorted spools
> --
>
> Key: IGNITE-16443
> URL: https://issues.apache.org/jira/browse/IGNITE-16443
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, calcite3-required
>
> Currently, the sorted spool comparator treats nulls in the search row as
> regular values and applies nulls ordering to them, but these nulls have
> another meaning: it means that any value matches the bound.
> For example, if we have the condition for spool {{a > 0}} it will be
> transformed to bounds: {{lower [0]}}, {{upper [null]}}, after comparing rows
> with lower bound we will get the correct result, but comparing with upper
> bound always give us {{1}} (value > null) with {{nulls first}} collation and
> no rows will be returned by index spool.
> For hash spool there is the reverse problem, we should not find rows if nulls
> are present in the search row, since condition NULL=NULL should not satisfy
> the filter in SQL.
> For index scan, there
[jira] [Updated] (IGNITE-16443) Calcite engine. Incorrect nulls in search row processing by hash/sorted spools
[
https://issues.apache.org/jira/browse/IGNITE-16443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16443:
---
Description:
Currently, the sorted spool comparator treats nulls in the search row as
regular values and applies nulls ordering to them, but these nulls have another
meaning: it means that any value matches the bound.
For example, if we have the condition for spool {{a > 0}} it will be
transformed to bounds: {{{}lower [0]{}}}, {{{}upper [null]{}}}, after comparing
rows with lower bound we will get the correct result, but comparing with upper
bound always give us {{1}} (value > null) with {{nulls first}} collation and no
rows will be returned by index spool.
For hash spool there is the reverse problem, we should not find rows if nulls
are present in the search row, since condition NULL=NULL should not satisfy the
filter in SQL.
For index scan, there are no problems that lead to data inconsistency, but in
the case of nulls in the search row, any value matches the bound and index scan
becomes very ineffective. For example, if we have the index by field {{a}} and
filter {{{}a = $cor0.b{}}}, for {{$cor0.b = null }}there will be the full index
scan, all rows will be passed to the predicate and 0 rows will be produced
after the predicate.
Another problem with comparators: there is a dead code in
{{ExpressionFactoryImpl#comparator(RelFieldCollation)}} which compare object by
hash or bytes:
* This code never executes since we support now only comparable types by
Calcite-based SQL engine
* Depends on H2
* Serialize object by standard java serialization
* Works only for ASC ordering
* Works for sort/spool/sort aggregate nodes, but doesn't work for merge join
I think we can get rid of this code at least until we don't support Object
types and revert corresponding changes to ignite-indexing to avoid merge
conflicts.
was:
Currently, the sorted spool comparator treats nulls in the search row as
regular values and applies nulls ordering to them, but these nulls have another
meaning: it means that any value matches the bound.
For example, if we have the condition for spool {{a > 0}} it will be
transformed to bounds: {{lower [0]}}, {{upper [null]}}, after comparing rows
with lower bound we will get the correct result, but comparing with upper bound
always give us {{1}} (value > null) with {{nulls first}} collation and no rows
will be returned by index spool.
For hash spool there is the reverse problem, we should not find rows if nulls
are present in the search row, since condition NULL=NULL should not satisfy the
filter in SQL.
Another problem with comparators: there is a dead code in
{{ExpressionFactoryImpl#comparator(RelFieldCollation)}} which compare object by
hash or bytes:
* This code never executes since we support now only comparable types by
Calcite-based SQL engine
* Depends on H2
* Serialize object by standard java serialization
* Works only for ASC ordering
* Works for sort/spool/sort aggregate nodes, but doesn't work for merge join
I think we can get rid of this code at least until we don't support Object
types and revert corresponding changes to ignite-indexing to avoid merge
conflicts.
> Calcite engine. Incorrect nulls in search row processing by hash/sorted spools
> --
>
> Key: IGNITE-16443
> URL: https://issues.apache.org/jira/browse/IGNITE-16443
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, calcite3-required
>
> Currently, the sorted spool comparator treats nulls in the search row as
> regular values and applies nulls ordering to them, but these nulls have
> another meaning: it means that any value matches the bound.
> For example, if we have the condition for spool {{a > 0}} it will be
> transformed to bounds: {{{}lower [0]{}}}, {{{}upper [null]{}}}, after
> comparing rows with lower bound we will get the correct result, but comparing
> with upper bound always give us {{1}} (value > null) with {{nulls first}}
> collation and no rows will be returned by index spool.
> For hash spool there is the reverse problem, we should not find rows if nulls
> are present in the search row, since condition NULL=NULL should not satisfy
> the filter in SQL.
> For index scan, there are no problems that lead to data inconsistency, but in
> the case of nulls in the search row, any value matches the bound and index
> scan becomes very ineffective. For example, if we have the index by field
> {{a}} and filter {{{}a = $cor0.b{}}}, for {{$cor0.b = null }}there will be
> the full index scan, all rows will be passed to the predicate and 0 rows will
> be produced after the predicate.
[jira] [Created] (IGNITE-16443) Calcite engine. Incorrect nulls in search row processing by hash/sorted spools
Aleksey Plekhanov created IGNITE-16443:
--
Summary: Calcite engine. Incorrect nulls in search row processing
by hash/sorted spools
Key: IGNITE-16443
URL: https://issues.apache.org/jira/browse/IGNITE-16443
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Currently, the sorted spool comparator treats nulls in the search row as
regular values and applies nulls ordering to them, but these nulls have another
meaning: it means that any value matches the bound.
For example, if we have the condition for spool {{a > 0}} it will be
transformed to bounds: {{lower [0]}}, {{upper [null]}}, after comparing rows
with lower bound we will get the correct result, but comparing with upper bound
always give us {{1}} (value > null) with {{nulls first}} collation and no rows
will be returned by index spool.
For hash spool there is the reverse problem, we should not find rows if nulls
are present in the search row, since condition NULL=NULL should not satisfy the
filter in SQL.
Another problem with comparators: there is a dead code in
{{ExpressionFactoryImpl#comparator(RelFieldCollation)}} which compare object by
hash or bytes:
* This code never executes since we support now only comparable types by
Calcite-based SQL engine
* Depends on H2
* Serialize object by standard java serialization
* Works only for ASC ordering
* Works for sort/spool/sort aggregate nodes, but doesn't work for merge join
I think we can get rid of this code at least until we don't support Object
types and revert corresponding changes to ignite-indexing to avoid merge
conflicts.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16264) [PageMemoryImpl] PageRestore does not mark the restored page as dirty.
[
https://issues.apache.org/jira/browse/IGNITE-16264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17485078#comment-17485078
]
Aleksey Plekhanov commented on IGNITE-16264:
[~xtern] looks good to me.
> [PageMemoryImpl] PageRestore does not mark the restored page as dirty.
> --
>
> Key: IGNITE-16264
> URL: https://issues.apache.org/jira/browse/IGNITE-16264
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.11.1
>Reporter: Fedor Malchikov
>Assignee: Pavel Pereslegin
>Priority: Major
> Attachments: grid.1.node.2.log
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> {code:java}
> [15:53:09,313][INFO][main][GridCacheDatabaseSharedManager] Starting binary
> memory restore for: [1587982887, 1586135659, 1586135625, 1588907152,
> 1134507861, 1587059273, -2100569601, 374280889, 374280888, 374280887,
> 374280886, 374280885, 374280884,
> 1587059204][15:53:09,583][INFO][main][CheckpointMarkersStorage] Read
> checkpoint status
> [startMarker=/storage/ssd/prtagent/tiden/sow-220111-155046/test_iep_14/ignite.server.2/work/db/node_1_2/cp/1641905556201-40b99ac3-a6c5-48e6-956b-8b2b0a5804c9-START.bin,
>
> endMarker=/storage/ssd/prtagent/tiden/sow-220111-155046/test_iep_14/ignite.server.2/work/db/node_1_2/cp/1641905556201-40b99ac3-a6c5-48e6-956b-8b2b0a5804c9-END.bin][15:53:09,583][INFO][main][GridCacheDatabaseSharedManager]
> Checking memory state [lastValidPos=FileWALPointer [idx=41, fileOff=734466,
> len=52185], lastMarked=FileWALPointer [idx=41, fileOff=734466, len=52185],
> lastCheckpointId=40b99ac3-a6c5-48e6-956b-8b2b0a5804c9][15:53:09,588][INFO][main][GridCacheDatabaseSharedManager]
> Found last checkpoint marker [cpId=40b99ac3-a6c5-48e6-956b-8b2b0a5804c9,
> pos=FileWALPointer [idx=41, fileOff=734466,
> len=52185]][15:53:09,590][INFO][main][GridCacheDatabaseSharedManager] Binary
> memory state restored at node startup [restoredPtr=FileWALPointer [idx=41,
> fileOff=786651, len=0]][15:53:09,593][INFO][main][FileWriteAheadLogManager]
> Resuming logging to WAL segment
> [file=/storage/ssd/prtagent/tiden/sow-220111-155046/test_iep_14/ignite.server.2/work/db/wal/node_1_2/0001.wal,
> offset=786651, ver=2][15:53:09,611][INFO][main][PageMemoryImpl] Started page
> memory [memoryAllocated=500.0 MiB, pages=124064, tableSize=9.7 MiB,
> replacementSize=15.3 KiB, checkpointBuffer=256.0
> MiB][15:53:09,731][INFO][main][GridCacheProcessor] Started cache in recovery
> mode [name=cache_group_3_088, id=1587982887, dataRegionName=Default_Region,
> mode=PARTITIONED, atomicity=TRANSACTIONAL, backups=3,
> mvcc=false][15:53:09,769][INFO][main][GridCacheProcessor] Started cache in
> recovery mode [name=cache_group_1_028, id=1586135659,
> dataRegionName=Default_Region, mode=PARTITIONED, atomicity=TRANSACTIONAL,
> backups=3, mvcc=false][15:53:09,774][WARNING][main][PageMemoryImpl] Failed to
> read page (data integrity violation encountered, will try to restore using
> existing WAL) [fullPageId=FullPageId [pageId=0002,
> effectivePageId=, grpId=1134507861]]class
> org.apache.ignite.internal.processors.cache.persistence.wal.crc.IgniteDataIntegrityViolationException:
> Failed to read page (CRC validation failed) [id=0002, off=0,
> file=/storage/ssd/prtagent/tiden/sow-220111-155046/test_iep_14/ignite.server.2/work/db/node_1_2/cacheGroup-test_cache_group/index.bin,
> fileSize=24576, savedCrc=93303030, curCrc=93e69aca,
>
[jira] [Commented] (IGNITE-16191) Calcite engine. Unexpected result of COUNT with multiple parameters
[
https://issues.apache.org/jira/browse/IGNITE-16191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17484741#comment-17484741
]
Aleksey Plekhanov commented on IGNITE-16191:
Yes, it's not an SQL standard, but Calcite supports it. I think we should
either support it or throw a correct exception, but not return unexpected
results. Currently, it can be disabled by system property
{{calcite.strict.sql=true}} and looks like it is the only usage of this
property.
> Calcite engine. Unexpected result of COUNT with multiple parameters
> ---
>
> Key: IGNITE-16191
> URL: https://issues.apache.org/jira/browse/IGNITE-16191
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Aleksey Plekhanov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: calcite2-required, calcite3-required
>
> The calcite engine supports the {{COUNT}} aggregate function with multiple
> parameters. Such a function should return the number of input rows for which
> parameters are wholly not null.
> But currently queries like:
> {noformat}
> SELECT COUNT(null, 1)
> SELECT COUNT(1, null)
> {noformat}
> Return 0 (expected 1).
> Query:
> {noformat}
> SELECT COUNT(null, null)
> {noformat}
> Throw an exception:
> {noformat}
> Caused by: java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
> at java.util.ArrayList.rangeCheck(ArrayList.java:657)
> at java.util.ArrayList.get(ArrayList.java:433)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.agg.AccumulatorsFactory$WrapperPrototype$1.apply(AccumulatorsFactory.java:226)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.agg.AccumulatorsFactory$WrapperPrototype$1.apply(AccumulatorsFactory.java:223)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.agg.AccumulatorsFactory$AccumulatorWrapperImpl.add(AccumulatorsFactory.java:305)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.HashAggregateNode$Grouping.addOnMapper(HashAggregateNode.java:294)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.HashAggregateNode$Grouping.add(HashAggregateNode.java:265)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.HashAggregateNode$Grouping.access$100(HashAggregateNode.java:222)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.HashAggregateNode.push(HashAggregateNode.java:127)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.ScanNode.push(ScanNode.java:107)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16430) Calcite engine. Sorted index spool with sorting can't be planned
[
https://issues.apache.org/jira/browse/IGNITE-16430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17484663#comment-17484663
]
Aleksey Plekhanov commented on IGNITE-16430:
[~tledkov-gridgain], unfortunately, it will not work. I've tried to create a
new metadata handler, which computes rewind cost and use this cost in
correlated nested loop cumulative cost calculation, but there is a problem with
{{{}RelSubset{}}}. Subsets store only one best cost and only one rel operator
for this cost, but there can be different operators in one subset some of them
have better cumulative cost, some of them better rewind cost and total best
cost depends on the count of rewinds, so we can't store these best operators in
only one field. For example, if we have in one subset ({{{}filter + table
spool){}}} as one branch with cumulative cost {{cc1}} and rewind cost {{rc1}}
and {{(index spool + sort)}} as another branch with cumulative cost {{cc2}} and
rewind cost {{{}rc2{}}}, such as {{cc1 < cc2}} and {{{}rc1 > rc2{}}}, then the
first branch should be stored as best when we are not in the right branch of
the correlated nested loop, otherwise second branch should be stored as best.
> Calcite engine. Sorted index spool with sorting can't be planned
>
>
> Key: IGNITE-16430
> URL: https://issues.apache.org/jira/browse/IGNITE-16430
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, calcite3-required
>
> Currently, we have code in {{FilterSpoolMergeToSortedIndexSpoolRule}} that
> creates a sorted spool even if the input collation is empty. In this case,
> collation is created by index condition and the new sort node is inserted
> before the spool. But such a plan can never be chosen as the best plan since
> when we calculate the cumulative cost for the nested loop correlated join, we
> multiply left side rows count to right side commutative cost not taking into
> account rewind cost. Currently, cumulative cost for filter + spool = {{{}CPU:
> n + n{}}}, memory: {{{}0 + n{}}}, for sorted spool + sort = CPU: {{{}log n +
> n*log n{}}}, memory: {{{}n + n{}}}. So, the cost for filter + spool will
> always be better than the cost for sorted spool + sort and sorted spool +
> sort never can be chosen. But for example, for sorted spool with sort rewind
> CPU cost is only {{log n}} since sorting is required only once and rewind CPU
> cost of filter + spool is {{{}n + n{}}}. So, starting from some iteration
> count cost of {{iterations * rewind cost + cumulative cost}} will be better
> than {{{}iterantions * cumulative cost{}}}, and sorted spool + sort will be
> chosen in this case.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16430) Calcite engine. Sorted index spool with sorting can't be planned
[
https://issues.apache.org/jira/browse/IGNITE-16430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16430:
---
Summary: Calcite engine. Sorted index spool with sorting can't be planned
(was: Calcite engine. Sorted index spool with sorting can be planned)
> Calcite engine. Sorted index spool with sorting can't be planned
>
>
> Key: IGNITE-16430
> URL: https://issues.apache.org/jira/browse/IGNITE-16430
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, calcite3-required
>
> Currently, we have code in {{FilterSpoolMergeToSortedIndexSpoolRule}} that
> creates a sorted spool even if the input collation is empty. In this case,
> collation is created by index condition and the new sort node is inserted
> before the spool. But such a plan can never be chosen as the best plan since
> when we calculate the cumulative cost for the nested loop correlated join, we
> multiply left side rows count to right side commutative cost not taking into
> account rewind cost. Currently, cumulative cost for filter + spool = {{{}CPU:
> n + n{}}}, memory: {{{}0 + n{}}}, for sorted spool + sort = CPU: {{{}log n +
> n*log n{}}}, memory: {{{}n + n{}}}. So, the cost for filter + spool will
> always be better than the cost for sorted spool + sort and sorted spool +
> sort never can be chosen. But for example, for sorted spool with sort rewind
> CPU cost is only {{log n}} since sorting is required only once and rewind CPU
> cost of filter + spool is {{{}n + n{}}}. So, starting from some iteration
> count cost of {{iterations * rewind cost + cumulative cost}} will be better
> than {{{}iterantions * cumulative cost{}}}, and sorted spool + sort will be
> chosen in this case.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16430) Calcite engine. Sorted index spool with sorting can be planned
[
https://issues.apache.org/jira/browse/IGNITE-16430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16430:
---
Labels: calcite2-required calcite3-required (was: )
> Calcite engine. Sorted index spool with sorting can be planned
> --
>
> Key: IGNITE-16430
> URL: https://issues.apache.org/jira/browse/IGNITE-16430
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, calcite3-required
>
> Currently, we have code in {{FilterSpoolMergeToSortedIndexSpoolRule}} that
> creates a sorted spool even if the input collation is empty. In this case,
> collation is created by index condition and the new sort node is inserted
> before the spool. But such a plan can never be chosen as the best plan since
> when we calculate the cumulative cost for the nested loop correlated join, we
> multiply left side rows count to right side commutative cost not taking into
> account rewind cost. Currently, cumulative cost for filter + spool = {{{}CPU:
> n + n{}}}, memory: {{{}0 + n{}}}, for sorted spool + sort = CPU: {{{}log n +
> n*log n{}}}, memory: {{{}n + n{}}}. So, the cost for filter + spool will
> always be better than the cost for sorted spool + sort and sorted spool +
> sort never can be chosen. But for example, for sorted spool with sort rewind
> CPU cost is only {{log n}} since sorting is required only once and rewind CPU
> cost of filter + spool is {{{}n + n{}}}. So, starting from some iteration
> count cost of {{iterations * rewind cost + cumulative cost}} will be better
> than {{{}iterantions * cumulative cost{}}}, and sorted spool + sort will be
> chosen in this case.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16430) Calcite engine. Sorted index spool with sorting can be planned
[
https://issues.apache.org/jira/browse/IGNITE-16430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16430:
---
Description: Currently, we have code in
{{FilterSpoolMergeToSortedIndexSpoolRule}} that creates a sorted spool even if
the input collation is empty. In this case, collation is created by index
condition and the new sort node is inserted before the spool. But such a plan
can never be chosen as the best plan since when we calculate the cumulative
cost for the nested loop correlated join, we multiply left side rows count to
right side commutative cost not taking into account rewind cost. Currently,
cumulative cost for filter + spool = {{{}CPU: n + n{}}}, memory: {{{}0 + n{}}},
for sorted spool + sort = CPU: {{{}log n + n*log n{}}}, memory: {{{}n + n{}}}.
So, the cost for filter + spool will always be better than the cost for sorted
spool + sort and sorted spool + sort never can be chosen. But for example, for
sorted spool with sort rewind CPU cost is only {{log n}} since sorting is
required only once and rewind CPU cost of filter + spool is {{{}n + n{}}}. So,
starting from some iteration count cost of {{iterations * rewind cost +
cumulative cost}} will be better than {{{}iterantions * cumulative cost{}}},
and sorted spool + sort will be chosen in this case. (was: Currently, we have
code in {{FilterSpoolMergeToSortedIndexSpoolRule}} that creates a sorted spool
even if the input collation is empty. In this case, collation is created by
index condition and the new sort node is inserted before the spool. But such a
plan can never be chosen as the best plan since when we calculate the
cumulative cost for the nested loop correlated join, we multiply left side rows
count to right side commutative cost not taking into account rewind cost.
Currently, cumulative cost for filter + spool = {{CPU: n + n}}, memory: {{0 +
n}}, for sorted spool + sort = CPU: {{log n+ n*log n}}, memory: {{n + n}}. So,
the cost for filter + spool will always be better than the cost for sorted
spool + sort and sorted spool + sort never can be chosen. But for example, for
sorted spool with sort rewind CPU cost is only {{log n}} since sorting is
required only once and rewind CPU cost of filter + spool is {{n + n}}. So,
starting from some iteration count cost of {{iterations * rewind cost +
cumulative cost}} will be better than {{iterantions * cumulative cost}}, and
sorted spool + sort will be chosen in this case.)
> Calcite engine. Sorted index spool with sorting can be planned
> --
>
> Key: IGNITE-16430
> URL: https://issues.apache.org/jira/browse/IGNITE-16430
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Priority: Major
>
> Currently, we have code in {{FilterSpoolMergeToSortedIndexSpoolRule}} that
> creates a sorted spool even if the input collation is empty. In this case,
> collation is created by index condition and the new sort node is inserted
> before the spool. But such a plan can never be chosen as the best plan since
> when we calculate the cumulative cost for the nested loop correlated join, we
> multiply left side rows count to right side commutative cost not taking into
> account rewind cost. Currently, cumulative cost for filter + spool = {{{}CPU:
> n + n{}}}, memory: {{{}0 + n{}}}, for sorted spool + sort = CPU: {{{}log n +
> n*log n{}}}, memory: {{{}n + n{}}}. So, the cost for filter + spool will
> always be better than the cost for sorted spool + sort and sorted spool +
> sort never can be chosen. But for example, for sorted spool with sort rewind
> CPU cost is only {{log n}} since sorting is required only once and rewind CPU
> cost of filter + spool is {{{}n + n{}}}. So, starting from some iteration
> count cost of {{iterations * rewind cost + cumulative cost}} will be better
> than {{{}iterantions * cumulative cost{}}}, and sorted spool + sort will be
> chosen in this case.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16430) Calcite engine. Sorted index spool with sorting can be planned
[
https://issues.apache.org/jira/browse/IGNITE-16430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16430:
---
Description: Currently, we have code in
{{FilterSpoolMergeToSortedIndexSpoolRule}} that creates a sorted spool even if
the input collation is empty. In this case, collation is created by index
condition and the new sort node is inserted before the spool. But such a plan
can never be chosen as the best plan since when we calculate the cumulative
cost for the nested loop correlated join, we multiply left side rows count to
right side commutative cost not taking into account rewind cost. Currently,
cumulative cost for filter + spool = {{CPU: n + n}}, memory: {{0 + n}}, for
sorted spool + sort = CPU: {{log n+ n*log n}}, memory: {{n + n}}. So, the cost
for filter + spool will always be better than the cost for sorted spool + sort
and sorted spool + sort never can be chosen. But for example, for sorted spool
with sort rewind CPU cost is only {{log n}} since sorting is required only once
and rewind CPU cost of filter + spool is {{n + n}}. So, starting from some
iteration count cost of {{iterations * rewind cost + cumulative cost}} will be
better than {{iterantions * cumulative cost}}, and sorted spool + sort will be
chosen in this case. (was: Currently, we have code in
{{FilterSpoolMergeToSortedIndexSpoolRule}} that creates a sorted spool even if
the input collation is empty. In this case, collation is created by index
condition and the new sort node is inserted before the spool. But such a plan
can never be chosen as the best plan since when we calculate the cumulative
cost for the nested loop correlated join, we multiply left side rows count to
right side commutative cost not taking into account rewind cost. Currently,
cumulative cost for filter + spool = {{{}CPU: n + n{}}}, memory: {{{}0 + n{}}},
for sorted spool + sort = CPU: {{{}log(n)+ n*log(n){}}}, memory: {{{}n + n{}}}.
So, the cost for filter + spool will always be better than the cost for sorted
spool + sort and sorted spool + sort never can be chosen. But for example, for
sorted spool with sort rewind CPU cost is only {{log(n)}} since sorting is
required only once and rewind CPU cost of filter + spool is {{{}n + n{}}}. So,
starting from some iteration count cost of {{iterations * rewind cost +
cumulative cost}} will be better than {{{}iterantions * cumulative cost{}}},
and sorted spool + sort will be chosen in this case.)
> Calcite engine. Sorted index spool with sorting can be planned
> --
>
> Key: IGNITE-16430
> URL: https://issues.apache.org/jira/browse/IGNITE-16430
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Priority: Major
>
> Currently, we have code in {{FilterSpoolMergeToSortedIndexSpoolRule}} that
> creates a sorted spool even if the input collation is empty. In this case,
> collation is created by index condition and the new sort node is inserted
> before the spool. But such a plan can never be chosen as the best plan since
> when we calculate the cumulative cost for the nested loop correlated join, we
> multiply left side rows count to right side commutative cost not taking into
> account rewind cost. Currently, cumulative cost for filter + spool = {{CPU: n
> + n}}, memory: {{0 + n}}, for sorted spool + sort = CPU: {{log n+ n*log n}},
> memory: {{n + n}}. So, the cost for filter + spool will always be better than
> the cost for sorted spool + sort and sorted spool + sort never can be chosen.
> But for example, for sorted spool with sort rewind CPU cost is only {{log n}}
> since sorting is required only once and rewind CPU cost of filter + spool is
> {{n + n}}. So, starting from some iteration count cost of {{iterations *
> rewind cost + cumulative cost}} will be better than {{iterantions *
> cumulative cost}}, and sorted spool + sort will be chosen in this case.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16430) Calcite engine. Sorted index spool with sorting can be planned
[
https://issues.apache.org/jira/browse/IGNITE-16430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16430:
---
Description: Currently, we have code in
{{FilterSpoolMergeToSortedIndexSpoolRule}} that creates a sorted spool even if
the input collation is empty. In this case, collation is created by index
condition and the new sort node is inserted before the spool. But such a plan
can never be chosen as the best plan since when we calculate the cumulative
cost for the nested loop correlated join, we multiply left side rows count to
right side commutative cost not taking into account rewind cost. Currently,
cumulative cost for filter + spool = {{{}CPU: n + n{}}}, memory: {{{}0 + n{}}},
for sorted spool + sort = CPU: {{{}log(n)+ n*log(n){}}}, memory: {{{}n + n{}}}.
So, the cost for filter + spool will always be better than the cost for sorted
spool + sort and sorted spool + sort never can be chosen. But for example, for
sorted spool with sort rewind CPU cost is only {{log(n)}} since sorting is
required only once and rewind CPU cost of filter + spool is {{{}n + n{}}}. So,
starting from some iteration count cost of {{iterations * rewind cost +
cumulative cost}} will be better than {{{}iterantions * cumulative cost{}}},
and sorted spool + sort will be chosen in this case. (was: Currently, we have
code in {{FilterSpoolMergeToSortedIndexSpoolRule}} that creates a sorted spool
even if the input collation is empty. In this case, collation is created by
index condition and the new sort node is inserted before the spool. But such a
plan can never be chosen as the best plan since when we calculate the
cumulative cost for the nested loop correlated join, we multiply left side rows
count to right side commutative cost not taking into account rewind cost.
Currently, cumulative cost for filter + spool = {{{}CPU: n + n{}}}, memory:
{{{}0 + n{}}}, for sorted spool + sort = CPU: {{{}log(n) + n*log(n){}}},
memory: \{{n + n}}. So, the cost for filter + spool will always be better than
the cost for sorted spool + sort and sorted spool + sort never can be chosen.
But for example, for sorted spool with sort rewind CPU cost is only {{log(n)}}
since sorting is required only once and rewind CPU cost of filter + spool is
{{{}n + n{}}}. So, starting from some iteration count cost of {{iterations *
rewind cost + cumulative cost}} will be better than {{{}iterantions *
cumulative cost{}}}, and sorted spool + sort will be chosen in this case.)
> Calcite engine. Sorted index spool with sorting can be planned
> --
>
> Key: IGNITE-16430
> URL: https://issues.apache.org/jira/browse/IGNITE-16430
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Priority: Major
>
> Currently, we have code in {{FilterSpoolMergeToSortedIndexSpoolRule}} that
> creates a sorted spool even if the input collation is empty. In this case,
> collation is created by index condition and the new sort node is inserted
> before the spool. But such a plan can never be chosen as the best plan since
> when we calculate the cumulative cost for the nested loop correlated join, we
> multiply left side rows count to right side commutative cost not taking into
> account rewind cost. Currently, cumulative cost for filter + spool = {{{}CPU:
> n + n{}}}, memory: {{{}0 + n{}}}, for sorted spool + sort = CPU: {{{}log(n)+
> n*log(n){}}}, memory: {{{}n + n{}}}. So, the cost for filter + spool will
> always be better than the cost for sorted spool + sort and sorted spool +
> sort never can be chosen. But for example, for sorted spool with sort rewind
> CPU cost is only {{log(n)}} since sorting is required only once and rewind
> CPU cost of filter + spool is {{{}n + n{}}}. So, starting from some iteration
> count cost of {{iterations * rewind cost + cumulative cost}} will be better
> than {{{}iterantions * cumulative cost{}}}, and sorted spool + sort will be
> chosen in this case.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16430) Calcite engine. Sorted index spool with sorting can be planned
Aleksey Plekhanov created IGNITE-16430:
--
Summary: Calcite engine. Sorted index spool with sorting can be
planned
Key: IGNITE-16430
URL: https://issues.apache.org/jira/browse/IGNITE-16430
Project: Ignite
Issue Type: Improvement
Reporter: Aleksey Plekhanov
Currently, we have code in {{FilterSpoolMergeToSortedIndexSpoolRule}} that
creates a sorted spool even if the input collation is empty. In this case,
collation is created by index condition and the new sort node is inserted
before the spool. But such a plan can never be chosen as the best plan since
when we calculate the cumulative cost for the nested loop correlated join, we
multiply left side rows count to right side commutative cost not taking into
account rewind cost. Currently, cumulative cost for filter + spool = {{{}CPU: n
+ n{}}}, memory: {{{}0 + n{}}}, for sorted spool + sort = CPU: {{{}log(n) +
n*log(n){}}}, memory: \{{n + n}}. So, the cost for filter + spool will always
be better than the cost for sorted spool + sort and sorted spool + sort never
can be chosen. But for example, for sorted spool with sort rewind CPU cost is
only {{log(n)}} since sorting is required only once and rewind CPU cost of
filter + spool is {{{}n + n{}}}. So, starting from some iteration count cost of
{{iterations * rewind cost + cumulative cost}} will be better than
{{{}iterantions * cumulative cost{}}}, and sorted spool + sort will be chosen
in this case.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16414) Calcite engine. Sorted index spool produces wrong collation
[ https://issues.apache.org/jira/browse/IGNITE-16414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-16414: --- Labels: calcite2-required calcite3-required (was: ) > Calcite engine. Sorted index spool produces wrong collation > --- > > Key: IGNITE-16414 > URL: https://issues.apache.org/jira/browse/IGNITE-16414 > Project: Ignite > Issue Type: Bug >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: calcite2-required, calcite3-required > > The sorted index spool does not take into account input collation directions > and null ordering. When generating collation based on conditions, default > direction and null ordering are used. This leads to wrong planning in case of > not default null ordering (additional sort node inserted even if we iterating > by index with required collation) and wrong index conditions usage in case of > descending direction (upper and lower bound are inverted for DESC direction). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16414) Calcite engine. Sorted index spool produces wrong collation
Aleksey Plekhanov created IGNITE-16414: -- Summary: Calcite engine. Sorted index spool produces wrong collation Key: IGNITE-16414 URL: https://issues.apache.org/jira/browse/IGNITE-16414 Project: Ignite Issue Type: Bug Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov The sorted index spool does not take into account input collation directions and null ordering. When generating collation based on conditions, default direction and null ordering are used. This leads to wrong planning in case of not default null ordering (additional sort node inserted even if we iterating by index with required collation) and wrong index conditions usage in case of descending direction (upper and lower bound are inverted for DESC direction). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16397) Calcite engine. Failed to insert to table with two or more columns in primary keys
[
https://issues.apache.org/jira/browse/IGNITE-16397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16397:
---
Labels: calcite2-required calcite3-required (was: )
> Calcite engine. Failed to insert to table with two or more columns in primary
> keys
> --
>
> Key: IGNITE-16397
> URL: https://issues.apache.org/jira/browse/IGNITE-16397
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, calcite3-required
>
> For example:
> {noformat}
> CREATE TABLE t(id INT, val VARCHAR, PRIMARY KEY(id, val));
> INSERT INTO t(id, val) VALUES (1, 'a');
> {noformat}
> Fails with:
> {noformat}
> Failed processing message [senderId=8aec0b77-e5a2-49b5-8f77-0f0a7771,
> msg=GridNearAtomicUpdateResponse
> [nodeId=235d7fbc-2a05-4d8b-8e37-3dff3980fc76, futId=1, errs=null,
> ret=GridCacheReturn [v=HashMap
> {SQL_PUBLIC_T_a975cf68_1738_43ca_915b_a52e6b89c049_KEY [idHash=1524322354,
> hash=-904731590, VAL=a, ID=1]=CacheInvokeResult [res=1, err=null]},
> cacheObj=null, success=false, invokeRes=true, loc=true, cacheId=-1578586257],
> remapTopVer=null, nearUpdates=null, partId=552, mapping=ArrayList [],
> nodeLeft=false, super=GridCacheIdMessage [cacheId=-1578586257,
> super=GridCacheMessage [msgId=30, depInfo=null,
> lastAffChangedTopVer=AffinityTopologyVersion [topVer=-1, minorTopVer=0],
> err=null, skipPrepare=false
> class org.apache.ignite.binary.BinaryInvalidTypeException:
> SQL_PUBLIC_T_a975cf68_1738_43ca_915b_a52e6b89c049_KEY
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:719)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1772)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1731)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:826)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:156)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:199)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinariesIfNeeded(CacheObjectUtils.java:126)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:205)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinaryIfNeeded(CacheObjectUtils.java:78)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:138)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1795)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1782)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.completeFuture(GridNearAtomicAbstractUpdateFuture.java:353)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.onPrimaryResponse(GridNearAtomicUpdateFuture.java:467)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateResponse(GridDhtAtomicCache.java:3207)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$500(GridDhtAtomicCache.java:143)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:303)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:298)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1151)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:592)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:393)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:110)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:309)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1909)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1530)
> at
>
[jira] [Created] (IGNITE-16397) Calcite engine. Failed to insert to table with two or more columns in primary keys
Aleksey Plekhanov created IGNITE-16397:
--
Summary: Calcite engine. Failed to insert to table with two or
more columns in primary keys
Key: IGNITE-16397
URL: https://issues.apache.org/jira/browse/IGNITE-16397
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
For example:
{noformat}
CREATE TABLE t(id INT, val VARCHAR, PRIMARY KEY(id, val));
INSERT INTO t(id, val) VALUES (1, 'a');
{noformat}
Fails with:
{noformat}
Failed processing message [senderId=8aec0b77-e5a2-49b5-8f77-0f0a7771,
msg=GridNearAtomicUpdateResponse [nodeId=235d7fbc-2a05-4d8b-8e37-3dff3980fc76,
futId=1, errs=null, ret=GridCacheReturn [v=HashMap
{SQL_PUBLIC_T_a975cf68_1738_43ca_915b_a52e6b89c049_KEY [idHash=1524322354,
hash=-904731590, VAL=a, ID=1]=CacheInvokeResult [res=1, err=null]},
cacheObj=null, success=false, invokeRes=true, loc=true, cacheId=-1578586257],
remapTopVer=null, nearUpdates=null, partId=552, mapping=ArrayList [],
nodeLeft=false, super=GridCacheIdMessage [cacheId=-1578586257,
super=GridCacheMessage [msgId=30, depInfo=null,
lastAffChangedTopVer=AffinityTopologyVersion [topVer=-1, minorTopVer=0],
err=null, skipPrepare=false
class org.apache.ignite.binary.BinaryInvalidTypeException:
SQL_PUBLIC_T_a975cf68_1738_43ca_915b_a52e6b89c049_KEY
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:719)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1772)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1731)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:826)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:156)
at
org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:199)
at
org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinariesIfNeeded(CacheObjectUtils.java:126)
at
org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:205)
at
org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinaryIfNeeded(CacheObjectUtils.java:78)
at
org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:138)
at
org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1795)
at
org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1782)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.completeFuture(GridNearAtomicAbstractUpdateFuture.java:353)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.onPrimaryResponse(GridNearAtomicUpdateFuture.java:467)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateResponse(GridDhtAtomicCache.java:3207)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$500(GridDhtAtomicCache.java:143)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:303)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:298)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1151)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:592)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:393)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:110)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:309)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1909)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1530)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:243)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1423)
at
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:569)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at
[jira] [Updated] (IGNITE-16396) Calcite engine. Allow hash output distribution for aggregations
[
https://issues.apache.org/jira/browse/IGNITE-16396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16396:
---
Labels: calcite2-required calcite3-required (was: )
> Calcite engine. Allow hash output distribution for aggregations
>
>
> Key: IGNITE-16396
> URL: https://issues.apache.org/jira/browse/IGNITE-16396
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, calcite3-required
>
> Currently, we allow only single output distribution for aggregates, but looks
> like if we have hash input distribution and all grouping set contains all of
> the distribution keys we can make aggregation on remote nodes and produce
> hash output distribution with the same keys. This will reduce memory
> consumption on the initiator node and make some other optimizations possible.
> For example, query:
> {noformat}
> SELECT t1.aff_key, t2.cnt FROM t1 JOIN (SELECT aff_key, COUNT(*) AS cnt FROM
> t2 GROUP BY id) AS t2 ON t1.aff_key = t2.aff_key{noformat}
> Can do colocated join if both tables are colocated on {{{}aff_key{}}}.
> Currently, such a query does join on the initiator node.
> The same for set-ops (EXCEPT, INTERSECT).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16395) Calcite engine. Implement correct copy-on-write on schema objects change
[
https://issues.apache.org/jira/browse/IGNITE-16395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16395:
---
Labels: calcite2-required calcite3-required (was: )
> Calcite engine. Implement correct copy-on-write on schema objects change
>
>
> Key: IGNITE-16395
> URL: https://issues.apache.org/jira/browse/IGNITE-16395
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, calcite3-required
>
> Currently, we only copy the schemas list when any schema object changes (see
> {{{}SchemaHolderImpl.rebuild(){}}}), but it can lead to some problems. For
> example, during planning, if some index dropped concurrently there will be
> NPE after {{tbl.getIndex(String)}} in some rules. So, we should copy the
> table containing this index and copy the schema containing this table at
> least for DROP INDEX command.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16396) Calcite engine. Allow hash output distribution for aggregations
[
https://issues.apache.org/jira/browse/IGNITE-16396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16396:
---
Description:
Currently, we allow only single output distribution for aggregates, but looks
like if we have hash input distribution and all grouping set contains all of
the distribution keys we can make aggregation on remote nodes and produce hash
output distribution with the same keys. This will reduce memory consumption on
the initiator node and make some other optimizations possible.
For example, query:
{noformat}
SELECT t1.aff_key, t2.cnt FROM t1 JOIN (SELECT aff_key, COUNT(*) AS cnt FROM t2
GROUP BY id) AS t2 ON t1.aff_key = t2.aff_key{noformat}
Can do colocated join if both tables are colocated on {{{}aff_key{}}}.
Currently, such a query does join on the initiator node.
The same for set-ops (EXCEPT, INTERSECT).
was:
Currently, we allow only single output distribution for aggregates, but looks
like if we have hash input distribution and all grouping set contains all of
the distribution keys we can make aggregation on remote nodes and produce hash
output distribution with the same keys. This will reduce memory consumption on
the initiator node and make some other optimizations possible.
For example, query:
{noformat}
SELECT t1.aff_key, t2.cnt FROM t1 JOIN (SELECT aff_key, COUNT(*) AS cnt FROM t2
GROUP BY id) AS t2 ON t1.aff_key = t2.aff_key{noformat}
Can do colocated join if both tables are colocated on {{{}aff_key{}}}.
Currently, such a query does join on the initiator node.
> Calcite engine. Allow hash output distribution for aggregations
>
>
> Key: IGNITE-16396
> URL: https://issues.apache.org/jira/browse/IGNITE-16396
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>
> Currently, we allow only single output distribution for aggregates, but looks
> like if we have hash input distribution and all grouping set contains all of
> the distribution keys we can make aggregation on remote nodes and produce
> hash output distribution with the same keys. This will reduce memory
> consumption on the initiator node and make some other optimizations possible.
> For example, query:
> {noformat}
> SELECT t1.aff_key, t2.cnt FROM t1 JOIN (SELECT aff_key, COUNT(*) AS cnt FROM
> t2 GROUP BY id) AS t2 ON t1.aff_key = t2.aff_key{noformat}
> Can do colocated join if both tables are colocated on {{{}aff_key{}}}.
> Currently, such a query does join on the initiator node.
> The same for set-ops (EXCEPT, INTERSECT).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16396) Calcite engine. Allow hash output distribution for aggregations
Aleksey Plekhanov created IGNITE-16396:
--
Summary: Calcite engine. Allow hash output distribution for
aggregations
Key: IGNITE-16396
URL: https://issues.apache.org/jira/browse/IGNITE-16396
Project: Ignite
Issue Type: Improvement
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Currently, we allow only single output distribution for aggregates, but looks
like if we have hash input distribution and all grouping set contains all of
the distribution keys we can make aggregation on remote nodes and produce hash
output distribution with the same keys. This will reduce memory consumption on
the initiator node and make some other optimizations possible.
For example, query:
{noformat}
SELECT t1.aff_key, t2.cnt FROM t1 JOIN (SELECT aff_key, COUNT(*) AS cnt FROM t2
GROUP BY id) AS t2 ON t1.aff_key = t2.aff_key{noformat}
Can do colocated join if both tables are colocated on {{{}aff_key{}}}.
Currently, such a query does join on the initiator node.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16395) Calcite engine. Implement correct copy-on-write on schema objects change
Aleksey Plekhanov created IGNITE-16395:
--
Summary: Calcite engine. Implement correct copy-on-write on schema
objects change
Key: IGNITE-16395
URL: https://issues.apache.org/jira/browse/IGNITE-16395
Project: Ignite
Issue Type: Improvement
Reporter: Aleksey Plekhanov
Currently, we only copy the schemas list when any schema object changes (see
{{{}SchemaHolderImpl.rebuild(){}}}), but it can lead to some problems. For
example, during planning, if some index dropped concurrently there will be NPE
after {{tbl.getIndex(String)}} in some rules. So, we should copy the table
containing this index and copy the schema containing this table at least for
DROP INDEX command.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
