[jira] [Created] (IGNITE-21507) Improve test coverege for colocation functionality
Yury Gerzhedovich created IGNITE-21507: -- Summary: Improve test coverege for colocation functionality Key: IGNITE-21507 URL: https://issues.apache.org/jira/browse/IGNITE-21507 Project: Ignite Issue Type: Improvement Reporter: Yury Gerzhedovich During implementation of IGNITE-16603 were added set of tests. However added set of tests is insufficient. Let's increase testc coverage for the following test cases: Integration tests: * Ensure colocation columns order leads to different distributions. * Ensure SQL JOIN on all the colocation columns leads to a plan with non-distributive join operation. * Ensure compute affinityCall always runs on the affinity node. Failover Testing: * Ensures colocation columns information survives grid restart. # Start a cluster. # Create a table with colocated columns specified. # Restart the cluster. # Check a Catalog table descriptor still contains colocation columns. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21505) Sql. Improve test coverage for case-sensitivity for name mapping
Yury Gerzhedovich created IGNITE-21505: -- Summary: Sql. Improve test coverage for case-sensitivity for name mapping Key: IGNITE-21505 URL: https://issues.apache.org/jira/browse/IGNITE-21505 Project: Ignite Issue Type: Improvement Components: sql Reporter: Yury Gerzhedovich During implementation of ticket IGNITE-16322 were added set of tests. However added set of tests is insufficient. Let's add the following test scenarios: h3. SQL API / JDBC * check that non-quoted object identifiers are accessible in case insensitive form. * check that quoted object identifiers are accessible only in quoted form. * checks should also apply to metadata APIs as well. h3. JDBC * check that case-sensitivity rules for object and column names are consistent with rules for SQL API. * checks should also apply to metadata APIs as well. h3. Table API * check that non-quoted table names are accessible in case-insensitive form. * check that quoted table names are accessible only in quoted form. * check that tuple fields are accessible in both quoted (case-sensitively) and unquoted (case-insensitive) forms. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21452) improve error handling in SQL module
[ https://issues.apache.org/jira/browse/IGNITE-21452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-21452: --- Description: As of now in case any uexpected error during SQL execution in SQL execution thread pool we can't simple to know the reason due to org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl log such error just on debug level and UncaughtExceptionHandler is not set. Let's fix both of the issues and check similar problem for another thread pools. was: As of now in case any uexpected error during SQL execution in SQL execution thread pool we can't simple to know the reason due to org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl log such error just on debug level and UncaughtExceptionHandler is not set. Let's fix both of the issues and check similar problem for another thread pools. > improve error handling in SQL module > > > Key: IGNITE-21452 > URL: https://issues.apache.org/jira/browse/IGNITE-21452 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > As of now in case any uexpected error during SQL execution in SQL execution > thread pool we can't simple to know the reason due to > org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl log such > error just on debug level and UncaughtExceptionHandler is not set. > Let's fix both of the issues and check similar problem for another thread > pools. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17165) ItProjectScanMergeRuleTest fails on Windows platform
[
https://issues.apache.org/jira/browse/IGNITE-17165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-17165:
---
Priority: Minor (was: Blocker)
> ItProjectScanMergeRuleTest fails on Windows platform
>
>
> Key: IGNITE-17165
> URL: https://issues.apache.org/jira/browse/IGNITE-17165
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Minor
> Labels: ignite-3
>
> The ItProjectScanMergeRuleTest.testProjects fails with the following error
> message:
> {noformat}
> java.lang.AssertionError: Invalid plan:
> IgniteExchange(distribution=[single]): rowcount = 1.0, cumulative cost =
> IgniteCost [rowCount=2.0, cpu=5.0, memory=0.0, io=0.0, network=4.0], id =
> 23507
> IgniteTableScan(table=[[PUBLIC, PRODUCTS]],
> tableId=[feaccfde-5e54-4e25-a911-7f7015c9a81e], tableVer=[1], filters=[>($t0,
> 1)], projects=[[$t1]], requiredColumns=[{2, 5}]): rowcount = 1.0, cumulative
> cost = IgniteCost [rowCount=1.0, cpu=4.0, memory=0.0, io=0.0, network=0.0],
> id = 23504
> Expected: a string contains ".*Ignite(Table|Index)Scan\\(table=\\[\\[PUBLIC,
> PRODUCTS\\]\\], .*requiredColumns=\\[\\{2, 5\\}\\].*"
> but: was "IgniteExchange(distribution=[single]): rowcount = 1.0,
> cumulative cost = IgniteCost [rowCount=2.0, cpu=5.0, memory=0.0, io=0.0,
> network=4.0], id = 23507
> IgniteTableScan(table=[[PUBLIC, PRODUCTS]],
> tableId=[feaccfde-5e54-4e25-a911-7f7015c9a81e], tableVer=[1], filters=[>($t0,
> 1)], projects=[[$t1]], requiredColumns=[{2, 5}]): rowcount = 1.0, cumulative
> cost = IgniteCost [rowCount=1.0, cpu=4.0, memory=0.0, io=0.0, network=0.0],
> id = 23504
> "
> {noformat}
> The root cause is that _QueryChecker_ uses "\n" as a line separator instead
> of "\r\n"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-16684) Different tests coverage number on PR without changes.
[ https://issues.apache.org/jira/browse/IGNITE-16684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich resolved IGNITE-16684. Resolution: Cannot Reproduce > Different tests coverage number on PR without changes. > -- > > Key: IGNITE-16684 > URL: https://issues.apache.org/jira/browse/IGNITE-16684 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 3.0.0-alpha5 >Reporter: Evgeny Stanilovsky >Assignee: Petr Ivanov >Priority: Blocker > Labels: ignite-3 > Attachments: image-2022-03-14-10-42-50-093.png, > image-2022-03-14-10-45-22-423.png, image-2022-03-14-10-45-46-028.png > > > For example on *main* branch : > !image-2022-03-14-10-42-50-093.png! > also test results are available for example for : ItDataTypesTest and *NOT* > available for ItDmlTest > !image-2022-03-14-10-45-22-423.png! > !image-2022-03-14-10-45-46-028.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-16562) ItSortAggregateTest.initTestData is flaky
[
https://issues.apache.org/jira/browse/IGNITE-16562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich resolved IGNITE-16562.
Resolution: Cannot Reproduce
> ItSortAggregateTest.initTestData is flaky
> -
>
> Key: IGNITE-16562
> URL: https://issues.apache.org/jira/browse/IGNITE-16562
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Semyon Danilov
>Priority: Blocker
> Labels: ignite-3
> Attachments: _Integration_Tests_Module_Runner_1655.log
>
>
> ItSortAggregateTest#initTestData could not be completed because of spamming
> {noformat}
> 2022-02-15 12:34:59:608 +0300
> [ERROR][%ItSortAggregateTest_null_2%Raft-Group-Client-8][RaftGroupServiceImpl]
> Failed to refresh a leader
> [groupId=a6328a6b-7da8-4a8f-a1b5-a27c75c6007b_part_9]
> java.util.concurrent.CompletionException:
> java.util.concurrent.TimeoutException
> at
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
> at
> java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
> at
> java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:632)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:502)
> at
> org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl$1.lambda$accept$1(RaftGroupServiceImpl.java:544)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.util.concurrent.TimeoutException
> {noformat}
> Log contains suspicious warnings from scalecube on a very beginning
> {noformat}
> [12:34:57]W: [org.apache.ignite:ignite-runner] 2022-02-15
> 12:34:46:180 +0300 [WARNING][sc-cluster-3345-150][MetadataStore]
> [default:ItSortAggregateTest_null_1:03483828-9532-4700-8fce-538486364fdf@172.17.0.6:3345][03483828-9532-4700-8fce-538486364fdf-1644917650003]
> Timeout getting GetMetadataResp from 172.17.0.6:3346 within 1000 ms, cause:
> java.util.concurrent.TimeoutException: Did not observe any item or terminal
> signal within 1000ms in 'source(MonoDefer)' (and no fallback has been
> configured)
> [12:34:57]W: [org.apache.ignite:ignite-runner] 2022-02-15
> 12:34:46:180 +0300 [WARNING][sc-cluster-3345-150][MembershipProtocol]
> [default:ItSortAggregateTest_null_1:03483828-9532-4700-8fce-538486364fdf@172.17.0.6:3345][updateMembership][SYNC]
> Skipping to add/update member: {m:
> default:ItSortAggregateTest_null_2:40801246-c98f-4db1-8acd-bcda982bd343@172.17.0.6:3346,
> s: ALIVE, inc: 0}, due to failed fetchMetadata call (cause:
> java.util.concurrent.TimeoutException: Did not observe any item or terminal
> signal within 1000ms in 'source(MonoDefer)' (and no fallback has been
> configured))
> [12:34:57]W: [org.apache.ignite:ignite-runner] 2022-02-15
> 12:34:46:180 +0300 [WARNING][sc-cluster-3345-150][MetadataStore]
> [default:ItSortAggregateTest_null_1:03483828-9532-4700-8fce-538486364fdf@172.17.0.6:3345][03483828-9532-4700-8fce-538486364fdf-1644917650004]
> Timeout getting GetMetadataResp from 172.17.0.6:3346 within 1000 ms, cause:
> java.util.concurrent.TimeoutException: Did not observe any item or terminal
> signal within 1000ms in 'source(MonoDefer)' (and no fallback has been
> configured)
> [12:34:57]W: [org.apache.ignite:ignite-runner] 2022-02-15
> 12:34:46:180 +0300 [WARNING][sc-cluster-3345-150][MembershipProtocol]
> [default:ItSortAggregateTest_null_1:03483828-9532-4700-8fce-538486364fdf@172.17.0.6:3345][updateMembership][SYNC]
> Skipping to add/update member: {m:
> default:ItSortAggregateTest_null_2:40801246-c98f-4db1-8acd-bcda982bd343@172.17.0.6:3346,
> s: ALIVE, inc: 0}, due to failed fetchMetadata call (cause:
> java.util.concurrent.TimeoutException: Did not observe any item or terminal
> signal within 1000ms in 'source(MonoDefer)' (and no fallback has been
> configured))
> [12:34:57]W: [org.apache.ignite:ignite-runner] 2022-02-15
> 12:34:46:181 +0300 [WARNING][sc-cluster-3345-150][MetadataStore]
>
[jira] [Updated] (IGNITE-19962) Actualize list of 3rd party dependencies for AI 3.0
[ https://issues.apache.org/jira/browse/IGNITE-19962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-19962: --- Priority: Blocker (was: Major) > Actualize list of 3rd party dependencies for AI 3.0 > --- > > Key: IGNITE-19962 > URL: https://issues.apache.org/jira/browse/IGNITE-19962 > Project: Ignite > Issue Type: Improvement >Reporter: Yury Gerzhedovich >Priority: Blocker > Labels: ignite-3 > > AI3 codestyle guide contains part about using 3rd party libraries. Right now > the document present just 5 such libraries, however we already use > signifignetely more. > Let's do two steps: > # analizy which dependencies could be get rid, even in tests. We must have > minimum dependency for whole project. > # Actualize list of 3rd party libraries in > [codestyle|https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries]]. > The first step should be discussed at developers mailing list and have strong > explanation of necessety for each of dependencies. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19608) Startup errors are ignored in ignite3db script
[
https://issues.apache.org/jira/browse/IGNITE-19608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-19608:
---
Priority: Blocker (was: Major)
> Startup errors are ignored in ignite3db script
> --
>
> Key: IGNITE-19608
> URL: https://issues.apache.org/jira/browse/IGNITE-19608
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta1, 3.0.0-beta2
>Reporter: Andrey Khitrin
>Priority: Blocker
> Labels: cli, ignite-3
>
> Ignite3 node is started by `bin/ignite3db` shell script. Unfortunately, this
> script follows some shell scripting bad practices that makes troubleshooting
> harder when something goes wrong.
> Particullary, there are following issues:
> 1. No guarding bash options (like `nounset`, `errexit`, or `pipefile`) is set.
> 2. When starting Java application, its stderr and stdout are redirected into
> `/dev/null`.
> {code:bash}
> CMD="${JAVA_CMD_WITH_ARGS} ${APPLICATION_ARGS}"
> $CMD >>/dev/null 2>&1 ${IGNITE_HOME}/pid
> {code}
> Just for comparison: [control.sh in
> AI2|https://github.com/apache/ignite/blob/master/bin/control.sh] do not
> suffer from such behavior. This should be fixed in AI3 too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-19744) Clean up IEP-54 leftovers
[ https://issues.apache.org/jira/browse/IGNITE-19744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich reassigned IGNITE-19744: -- Assignee: (was: Konstantin Orlov) > Clean up IEP-54 leftovers > - > > Key: IGNITE-19744 > URL: https://issues.apache.org/jira/browse/IGNITE-19744 > Project: Ignite > Issue Type: Improvement >Reporter: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > After migration from IEP-54 to IEP-92 binary format, there still a lot of > code working by old rules and used primarily in tests (see SchemaDescriptor > and all related classes). Let's clean up this code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21431) Datetime functions should return same value within transaction
[
https://issues.apache.org/jira/browse/IGNITE-21431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-21431:
---
Component/s: sql
> Datetime functions should return same value within transaction
> --
>
> Key: IGNITE-21431
> URL: https://issues.apache.org/jira/browse/IGNITE-21431
> Project: Ignite
> Issue Type: New Feature
> Components: sql
>Reporter: Maksim Myskov
>Priority: Major
> Labels: ignite-3
>
> It's guaranteed for datetime functions to be the same within a statement.
> From SQL standard:
> {quote}The s CURRENT_DATE, CURRENT_TIME, and
> CURRENT_TIMESTAMP
> respectively return the date, time, and timestamp from the current
> SQL-session context's statement times-
> tamp; the time and timestamp values are returned with time zone displacement
> equal to the current default
> time zone displacement of the SQL-session
> {quote}
>
> I believe it's an open question how to interpret the above, however,
> PostgreSQL, for example, states the following
> ([https://www.postgresql.org/docs/current/sql-createfunction.html|https://www.postgresql.org/docs/current/sql-createfunction.html:]):
> {quote}{{STABLE}} indicates that the function cannot modify the database, and
> that within a single table scan it will consistently return the same result
> for the same argument values, but that its result could change across SQL
> statements. This is the appropriate selection for functions whose results
> depend on database lookups, parameter variables (such as the current time
> zone), etc. (It is inappropriate for {{AFTER}} triggers that wish to query
> rows modified by the current command.) *Also note that the
> {{current_timestamp}} family of functions qualify as stable, since their
> values do not change within a transaction.*
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21472) Exception: Invalid length for a tuple element on prepared statement
[
https://issues.apache.org/jira/browse/IGNITE-21472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-21472:
---
Priority: Blocker (was: Major)
> Exception: Invalid length for a tuple element on prepared statement
> ---
>
> Key: IGNITE-21472
> URL: https://issues.apache.org/jira/browse/IGNITE-21472
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Igor
>Priority: Blocker
> Labels: ignite-3
>
> h3. Steps to reproduce:
> Run the next code:
> {code:java}
> try (Session session =
> IgniteClient.builder().addresses("localhost:10800").build().sql()
> .createSession();) {
> session.execute(null, "drop table if exists ttable");
> session.execute(null, "create table ttable("
> + "keyTINYINT0 TINYINT not null, "
> + "keySMALLINT1 SMALLINT not null, "
> + "keyINTEGER2 INTEGER not null, "
> + "keyTINYINT3 TINYINT not null, "
> + "val INTEGER not null, "
> + "primary key (keyTINYINT0, keySMALLINT1, keyINTEGER2,
> keyTINYINT3))");
> session.execute(null, "select keyTINYINT0, keySMALLINT1, keyINTEGER2,
> keyTINYINT3, val from ttable "
> + "where keyTINYINT0 = ? AND keySMALLINT1 = ? AND
> keyINTEGER2 = ? AND keyTINYINT3 = ? AND val = ? ",
> new Object[]{(byte) -87, (short)19507, 25781820, (byte)-84,
> 116522});
> } {code}
> h3. Expected:
> Run succesfully.
> *Actual:*
> The exception on the last statement:
> {code:java}
> org.apache.ignite.sql.SqlException: IGN-CMN-65535
> TraceId:cfa96929-079c-4434-a826-1eea7d307d3f Invalid length for a tuple
> element: 4
> at
> java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
> at
> org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:765)
> at
> org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:699)
> at
> org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:525)
> at
> org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:634)
> at
> org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:476)
> at
> org.apache.ignite.internal.sql.AbstractSession.execute(AbstractSession.java:63)
> at
> org.gridgain.ai3tests.tests.BasicAi3OperationsTest.testSaveAndGetFromCachee(BasicAi3OperationsTest.java:66)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
> Caused by: java.util.concurrent.CompletionException:
> org.apache.ignite.sql.SqlException: IGN-CMN-65535
> TraceId:cfa96929-079c-4434-a826-1eea7d307d3f Invalid length for a tuple
> element: 4
> at
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
> at
> java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
> at
> java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:870)
> at
> java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> org.apache.ignite.internal.client.TcpClientChannel.processNextMessage(TcpClientChannel.java:419)
> at
> org.apache.ignite.internal.client.TcpClientChannel.lambda$onMessage$3(TcpClientChannel.java:238)
> at
> java.base/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1426)
> at
> java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
> at
> java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
> at
> java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
> at
> java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
> at
> java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177)
> Caused by: org.apache.ignite.sql.SqlException: IGN-CMN-65535
> TraceId:cfa96929-079c-4434-a826-1eea7d307d3f Invalid length for a tuple
> element: 4
> at
> java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
> at
> org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:765)
> at
>
[jira] [Updated] (IGNITE-20294) Sql. Using UDF as a place for system_range function
[
https://issues.apache.org/jira/browse/IGNITE-20294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-20294:
---
Summary: Sql. Using UDF as a place for system_range function (was: Sql.
Investigate using UDF as a place for system_range function)
> Sql. Using UDF as a place for system_range function
> ---
>
> Key: IGNITE-20294
> URL: https://issues.apache.org/jira/browse/IGNITE-20294
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> For now system_range implementation stores at RexImpTable, check:
> {noformat}
> map.put(TYPEOF, systemFunctionImplementor);
> map.put(SYSTEM_RANGE, systemFunctionImplementor);
> {noformat}
> Investigate the way this functions can be removed under UDF implementation.
> [1]
> https://stackoverflow.com/questions/44147819/adding-a-user-defined-function-to-
> calcite
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21452) improve error handling in SQL module
[ https://issues.apache.org/jira/browse/IGNITE-21452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-21452: --- Description: As of now in case any uexpected error during SQL execution in SQL execution thread pool we can't simple to know the reason due to org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl log such error just on debug level and UncaughtExceptionHandler is not set. Let's fix both of the issues and check similar problem for another thread pools. was: As of now in case any uexpected error during SQL execution in SQL execution thread pool we can't simple to know the reason due to org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl log such error just on debug level and UncaughtExceptionHandler is not set. Let's fix both of the issue and check similar problem for another thread pools. > improve error handling in SQL module > > > Key: IGNITE-21452 > URL: https://issues.apache.org/jira/browse/IGNITE-21452 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > As of now in case any uexpected error during SQL execution in SQL execution > thread pool we can't simple to know the reason due to > org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl log such > error just on debug level and UncaughtExceptionHandler is not set. > Let's fix both of the issues and check similar problem for another thread > pools. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21452) improve error handling in SQL module
Yury Gerzhedovich created IGNITE-21452: -- Summary: improve error handling in SQL module Key: IGNITE-21452 URL: https://issues.apache.org/jira/browse/IGNITE-21452 Project: Ignite Issue Type: Improvement Components: sql Reporter: Yury Gerzhedovich As of now in case any uexpected error during SQL execution in SQL execution thread pool we can't simple to know the reason due to org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl log such error just on debug level and UncaughtExceptionHandler is not set. Let's fix both of the issue and check similar problem for another thread pools. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19082) Describe Catalog operation flow in README and cleanup dead code.
[ https://issues.apache.org/jira/browse/IGNITE-19082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-19082: --- Description: Let's * ensure Catalog is used by default as a single schema management point by TableManager, IndexManager, SqlSchemaManager, SchemaRegistry. * Describe CatalogService operations in README.md * drop schema related code from configuration. * drop outdated code from TableManager, IndexManager, SqlSchemaManager, SchemaRegistry. * make a PR for merging feature branch to main (if applicable). * ensure there are end-to-end tests for the cases (if applicable) described in CatalogServiceSelfTest. Also drop InternalSchemaTest. * Let’s remove using/keeping schema name instaed of schema id (NewIndexEntry class as example) was: Let's * ensure Catalog is used by default as a single schema management point by TableManager, IndexManager, SqlSchemaManager, SchemaRegistry. * Describe CatalogService operations in README.md * drop schema related code from configuration. * drop outdated code from TableManager, IndexManager, SqlSchemaManager, SchemaRegistry. * make a PR for merging feature branch to main (if applicable). * ensure there are end-to-end tests for the cases (if applicable) described in CatalogServiceSelfTest. Also drop InternalSchemaTest. > Describe Catalog operation flow in README and cleanup dead code. > > > Key: IGNITE-19082 > URL: https://issues.apache.org/jira/browse/IGNITE-19082 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Let's > * ensure Catalog is used by default as a single schema management point by > TableManager, IndexManager, SqlSchemaManager, SchemaRegistry. > * Describe CatalogService operations in README.md > * drop schema related code from configuration. > * drop outdated code from TableManager, IndexManager, SqlSchemaManager, > SchemaRegistry. > * make a PR for merging feature branch to main (if applicable). > * ensure there are end-to-end tests for the cases (if applicable) described > in CatalogServiceSelfTest. Also drop InternalSchemaTest. > * Let’s remove using/keeping schema name instaed of schema id (NewIndexEntry > class as example) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21443) Ignite 3 can hangs on starting
[
https://issues.apache.org/jira/browse/IGNITE-21443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-21443:
---
Priority: Critical (was: Major)
> Ignite 3 can hangs on starting
> --
>
> Key: IGNITE-21443
> URL: https://issues.apache.org/jira/browse/IGNITE-21443
> Project: Ignite
> Issue Type: Bug
>Reporter: Yury Gerzhedovich
>Priority: Critical
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> If something goes wrong Ignite 3 starting just hangs instead of finish start
> and return control to user. Example is below.
> {code:java}
> (base)
> ygerzhedovich@ygerzhedovich-ThinkPad-P52s:~/Desktop/Ignite_3_distrib/gridgain-db-9.0.0-ea5/bin$
> ./ignite3db start
> Starting Ignite 3...
> SLF4J: No SLF4J providers were found.
> SLF4J: Defaulting to no-operation (NOP) logger implementation
> SLF4J: See https://www.slf4j.org/codes.html#noProviders for further details.
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:2248ddcc-80d5-434a-b4c8-fefdcda633c1 Unable to start
> [node=defaultNode]
> at
> org.apache.ignite.internal.app.IgniteImpl.handleStartException(IgniteImpl.java:1067)
> at org.apache.ignite.internal.app.IgniteImpl.start(IgniteImpl.java:1056)
> at
> org.apache.ignite.internal.app.IgnitionImpl.doStart(IgnitionImpl.java:198)
> at org.apache.ignite.internal.app.IgnitionImpl.start(IgnitionImpl.java:99)
> at org.apache.ignite.IgnitionManager.start(IgnitionManager.java:72)
> at org.apache.ignite.IgnitionManager.start(IgnitionManager.java:51)
> at org.apache.ignite.internal.app.IgniteRunner.call(IgniteRunner.java:48)
> at org.apache.ignite.internal.app.IgniteRunner.call(IgniteRunner.java:35)
> at picocli.CommandLine.executeUserObject(CommandLine.java:2041)
> at picocli.CommandLine.access$1500(CommandLine.java:148)
> at
> picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2461)
> at picocli.CommandLine$RunLast.handle(CommandLine.java:2453)
> at picocli.CommandLine$RunLast.handle(CommandLine.java:2415)
> at
> picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2273)
> at picocli.CommandLine$RunLast.execute(CommandLine.java:2417)
> at picocli.CommandLine.execute(CommandLine.java:2170)
> at org.apache.ignite.internal.app.IgniteRunner.start(IgniteRunner.java:60)
> at org.apache.ignite.internal.app.IgniteRunner.main(IgniteRunner.java:74)
> Caused by: org.apache.ignite.internal.lang.IgniteInternalException:
> IGN-CMN-65535 TraceId:2248ddcc-80d5-434a-b4c8-fefdcda633c1 While lock file:
> /home/ygerzhedovich/Desktop/Ignite_3_distrib/gridgain-db-9.0.0-ea5/work/vault/LOCK:
> Resource temporarily unavailable
> at
> org.apache.ignite.internal.vault.persistence.PersistentVaultService.start(PersistentVaultService.java:111)
> at
> org.apache.ignite.internal.vault.VaultManager.start(VaultManager.java:52)
> at
> org.apache.ignite.internal.app.LifecycleManager.startComponent(LifecycleManager.java:79)
> at org.apache.ignite.internal.app.IgniteImpl.start(IgniteImpl.java:937)
> ... 16 more
> Caused by: org.rocksdb.RocksDBException: While lock file:
> /home/ygerzhedovich/Desktop/Ignite_3_distrib/gridgain-db-9.0.0-ea5/work/vault/LOCK:
> Resource temporarily unavailable
> at org.rocksdb.RocksDB.open(Native Method)
> at org.rocksdb.RocksDB.open(RocksDB.java:249)
> at
> org.apache.ignite.internal.vault.persistence.PersistentVaultService.start(PersistentVaultService.java:109)
> ... 19 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21443) Ignite 3 can hangs on starting
Yury Gerzhedovich created IGNITE-21443:
--
Summary: Ignite 3 can hangs on starting
Key: IGNITE-21443
URL: https://issues.apache.org/jira/browse/IGNITE-21443
Project: Ignite
Issue Type: Bug
Reporter: Yury Gerzhedovich
If something goes wrong Ignite 3 starting just hangs instead of finish start
and return control to user. Example is below.
{code:java}
(base)
ygerzhedovich@ygerzhedovich-ThinkPad-P52s:~/Desktop/Ignite_3_distrib/gridgain-db-9.0.0-ea5/bin$
./ignite3db start
Starting Ignite 3...
SLF4J: No SLF4J providers were found.
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See https://www.slf4j.org/codes.html#noProviders for further details.
org.apache.ignite.lang.IgniteException: IGN-CMN-65535
TraceId:2248ddcc-80d5-434a-b4c8-fefdcda633c1 Unable to start [node=defaultNode]
at
org.apache.ignite.internal.app.IgniteImpl.handleStartException(IgniteImpl.java:1067)
at org.apache.ignite.internal.app.IgniteImpl.start(IgniteImpl.java:1056)
at
org.apache.ignite.internal.app.IgnitionImpl.doStart(IgnitionImpl.java:198)
at org.apache.ignite.internal.app.IgnitionImpl.start(IgnitionImpl.java:99)
at org.apache.ignite.IgnitionManager.start(IgnitionManager.java:72)
at org.apache.ignite.IgnitionManager.start(IgnitionManager.java:51)
at org.apache.ignite.internal.app.IgniteRunner.call(IgniteRunner.java:48)
at org.apache.ignite.internal.app.IgniteRunner.call(IgniteRunner.java:35)
at picocli.CommandLine.executeUserObject(CommandLine.java:2041)
at picocli.CommandLine.access$1500(CommandLine.java:148)
at
picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2461)
at picocli.CommandLine$RunLast.handle(CommandLine.java:2453)
at picocli.CommandLine$RunLast.handle(CommandLine.java:2415)
at
picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2273)
at picocli.CommandLine$RunLast.execute(CommandLine.java:2417)
at picocli.CommandLine.execute(CommandLine.java:2170)
at org.apache.ignite.internal.app.IgniteRunner.start(IgniteRunner.java:60)
at org.apache.ignite.internal.app.IgniteRunner.main(IgniteRunner.java:74)
Caused by: org.apache.ignite.internal.lang.IgniteInternalException:
IGN-CMN-65535 TraceId:2248ddcc-80d5-434a-b4c8-fefdcda633c1 While lock file:
/home/ygerzhedovich/Desktop/Ignite_3_distrib/gridgain-db-9.0.0-ea5/work/vault/LOCK:
Resource temporarily unavailable
at
org.apache.ignite.internal.vault.persistence.PersistentVaultService.start(PersistentVaultService.java:111)
at org.apache.ignite.internal.vault.VaultManager.start(VaultManager.java:52)
at
org.apache.ignite.internal.app.LifecycleManager.startComponent(LifecycleManager.java:79)
at org.apache.ignite.internal.app.IgniteImpl.start(IgniteImpl.java:937)
... 16 more
Caused by: org.rocksdb.RocksDBException: While lock file:
/home/ygerzhedovich/Desktop/Ignite_3_distrib/gridgain-db-9.0.0-ea5/work/vault/LOCK:
Resource temporarily unavailable
at org.rocksdb.RocksDB.open(Native Method)
at org.rocksdb.RocksDB.open(RocksDB.java:249)
at
org.apache.ignite.internal.vault.persistence.PersistentVaultService.start(PersistentVaultService.java:109)
... 19 more
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21443) Ignite 3 can hangs on starting
[
https://issues.apache.org/jira/browse/IGNITE-21443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-21443:
---
Labels: ignite-3 (was: )
> Ignite 3 can hangs on starting
> --
>
> Key: IGNITE-21443
> URL: https://issues.apache.org/jira/browse/IGNITE-21443
> Project: Ignite
> Issue Type: Bug
>Reporter: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> If something goes wrong Ignite 3 starting just hangs instead of finish start
> and return control to user. Example is below.
> {code:java}
> (base)
> ygerzhedovich@ygerzhedovich-ThinkPad-P52s:~/Desktop/Ignite_3_distrib/gridgain-db-9.0.0-ea5/bin$
> ./ignite3db start
> Starting Ignite 3...
> SLF4J: No SLF4J providers were found.
> SLF4J: Defaulting to no-operation (NOP) logger implementation
> SLF4J: See https://www.slf4j.org/codes.html#noProviders for further details.
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:2248ddcc-80d5-434a-b4c8-fefdcda633c1 Unable to start
> [node=defaultNode]
> at
> org.apache.ignite.internal.app.IgniteImpl.handleStartException(IgniteImpl.java:1067)
> at org.apache.ignite.internal.app.IgniteImpl.start(IgniteImpl.java:1056)
> at
> org.apache.ignite.internal.app.IgnitionImpl.doStart(IgnitionImpl.java:198)
> at org.apache.ignite.internal.app.IgnitionImpl.start(IgnitionImpl.java:99)
> at org.apache.ignite.IgnitionManager.start(IgnitionManager.java:72)
> at org.apache.ignite.IgnitionManager.start(IgnitionManager.java:51)
> at org.apache.ignite.internal.app.IgniteRunner.call(IgniteRunner.java:48)
> at org.apache.ignite.internal.app.IgniteRunner.call(IgniteRunner.java:35)
> at picocli.CommandLine.executeUserObject(CommandLine.java:2041)
> at picocli.CommandLine.access$1500(CommandLine.java:148)
> at
> picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2461)
> at picocli.CommandLine$RunLast.handle(CommandLine.java:2453)
> at picocli.CommandLine$RunLast.handle(CommandLine.java:2415)
> at
> picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2273)
> at picocli.CommandLine$RunLast.execute(CommandLine.java:2417)
> at picocli.CommandLine.execute(CommandLine.java:2170)
> at org.apache.ignite.internal.app.IgniteRunner.start(IgniteRunner.java:60)
> at org.apache.ignite.internal.app.IgniteRunner.main(IgniteRunner.java:74)
> Caused by: org.apache.ignite.internal.lang.IgniteInternalException:
> IGN-CMN-65535 TraceId:2248ddcc-80d5-434a-b4c8-fefdcda633c1 While lock file:
> /home/ygerzhedovich/Desktop/Ignite_3_distrib/gridgain-db-9.0.0-ea5/work/vault/LOCK:
> Resource temporarily unavailable
> at
> org.apache.ignite.internal.vault.persistence.PersistentVaultService.start(PersistentVaultService.java:111)
> at
> org.apache.ignite.internal.vault.VaultManager.start(VaultManager.java:52)
> at
> org.apache.ignite.internal.app.LifecycleManager.startComponent(LifecycleManager.java:79)
> at org.apache.ignite.internal.app.IgniteImpl.start(IgniteImpl.java:937)
> ... 16 more
> Caused by: org.rocksdb.RocksDBException: While lock file:
> /home/ygerzhedovich/Desktop/Ignite_3_distrib/gridgain-db-9.0.0-ea5/work/vault/LOCK:
> Resource temporarily unavailable
> at org.rocksdb.RocksDB.open(Native Method)
> at org.rocksdb.RocksDB.open(RocksDB.java:249)
> at
> org.apache.ignite.internal.vault.persistence.PersistentVaultService.start(PersistentVaultService.java:109)
> ... 19 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21443) Ignite 3 can hangs on starting
[
https://issues.apache.org/jira/browse/IGNITE-21443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-21443:
---
Fix Version/s: 3.0.0-beta2
> Ignite 3 can hangs on starting
> --
>
> Key: IGNITE-21443
> URL: https://issues.apache.org/jira/browse/IGNITE-21443
> Project: Ignite
> Issue Type: Bug
>Reporter: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> If something goes wrong Ignite 3 starting just hangs instead of finish start
> and return control to user. Example is below.
> {code:java}
> (base)
> ygerzhedovich@ygerzhedovich-ThinkPad-P52s:~/Desktop/Ignite_3_distrib/gridgain-db-9.0.0-ea5/bin$
> ./ignite3db start
> Starting Ignite 3...
> SLF4J: No SLF4J providers were found.
> SLF4J: Defaulting to no-operation (NOP) logger implementation
> SLF4J: See https://www.slf4j.org/codes.html#noProviders for further details.
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:2248ddcc-80d5-434a-b4c8-fefdcda633c1 Unable to start
> [node=defaultNode]
> at
> org.apache.ignite.internal.app.IgniteImpl.handleStartException(IgniteImpl.java:1067)
> at org.apache.ignite.internal.app.IgniteImpl.start(IgniteImpl.java:1056)
> at
> org.apache.ignite.internal.app.IgnitionImpl.doStart(IgnitionImpl.java:198)
> at org.apache.ignite.internal.app.IgnitionImpl.start(IgnitionImpl.java:99)
> at org.apache.ignite.IgnitionManager.start(IgnitionManager.java:72)
> at org.apache.ignite.IgnitionManager.start(IgnitionManager.java:51)
> at org.apache.ignite.internal.app.IgniteRunner.call(IgniteRunner.java:48)
> at org.apache.ignite.internal.app.IgniteRunner.call(IgniteRunner.java:35)
> at picocli.CommandLine.executeUserObject(CommandLine.java:2041)
> at picocli.CommandLine.access$1500(CommandLine.java:148)
> at
> picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2461)
> at picocli.CommandLine$RunLast.handle(CommandLine.java:2453)
> at picocli.CommandLine$RunLast.handle(CommandLine.java:2415)
> at
> picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2273)
> at picocli.CommandLine$RunLast.execute(CommandLine.java:2417)
> at picocli.CommandLine.execute(CommandLine.java:2170)
> at org.apache.ignite.internal.app.IgniteRunner.start(IgniteRunner.java:60)
> at org.apache.ignite.internal.app.IgniteRunner.main(IgniteRunner.java:74)
> Caused by: org.apache.ignite.internal.lang.IgniteInternalException:
> IGN-CMN-65535 TraceId:2248ddcc-80d5-434a-b4c8-fefdcda633c1 While lock file:
> /home/ygerzhedovich/Desktop/Ignite_3_distrib/gridgain-db-9.0.0-ea5/work/vault/LOCK:
> Resource temporarily unavailable
> at
> org.apache.ignite.internal.vault.persistence.PersistentVaultService.start(PersistentVaultService.java:111)
> at
> org.apache.ignite.internal.vault.VaultManager.start(VaultManager.java:52)
> at
> org.apache.ignite.internal.app.LifecycleManager.startComponent(LifecycleManager.java:79)
> at org.apache.ignite.internal.app.IgniteImpl.start(IgniteImpl.java:937)
> ... 16 more
> Caused by: org.rocksdb.RocksDBException: While lock file:
> /home/ygerzhedovich/Desktop/Ignite_3_distrib/gridgain-db-9.0.0-ea5/work/vault/LOCK:
> Resource temporarily unavailable
> at org.rocksdb.RocksDB.open(Native Method)
> at org.rocksdb.RocksDB.open(RocksDB.java:249)
> at
> org.apache.ignite.internal.vault.persistence.PersistentVaultService.start(PersistentVaultService.java:109)
> ... 19 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21341) Sql. Optimize way to execute insert
[ https://issues.apache.org/jira/browse/IGNITE-21341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich reassigned IGNITE-21341: -- Assignee: (was: Yury Gerzhedovich) > Sql. Optimize way to execute insert > --- > > Key: IGNITE-21341 > URL: https://issues.apache.org/jira/browse/IGNITE-21341 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > As of now we use common approach for all execution queries. > Obviously, we can use simple KV put for simple insert statement. Let's > analyze the AST to identify such simple insert and execute it in an > optimized way, avoiding the common complex path. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21373) SQL. Get rid of the Ignite prefix in SQL operators.
Yury Gerzhedovich created IGNITE-21373: -- Summary: SQL. Get rid of the Ignite prefix in SQL operators. Key: IGNITE-21373 URL: https://issues.apache.org/jira/browse/IGNITE-21373 Project: Ignite Issue Type: Improvement Components: sql Reporter: Yury Gerzhedovich Currently we have an Ignite prefix for all SQL statements for the text view of the plane (IgniteProject, IgniteNestedLoopJoin, IgniteTableScan, IgniteExchange, .). Let's get rid of the prefix. Since we are generating the name as a simple class name, we need to rework this part and introduce the ability to have a name independent of the class name for any operator. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21353) Sql. Support for choosing the primary key index type.
[
https://issues.apache.org/jira/browse/IGNITE-21353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-21353:
---
Description:
As of now we support choosing type just for secondary indexes, like a
_CREATE INDEX idx_name ON table *USING TREE* (column_name)_
But for PK we always create under the hood HASH index.
Let's introduce ability to choose type for PK by the analogy with a secondary
indexes;
it should be add an optional parameter *USING type* for PRIMARY KEY definition
and add ability set collation for columns including into PK)
CREATE TABLE . (..., PRIMARY KEY *[ USING SORTED | HASH ]* (column1,
column2, ... column_n)) ...)
as example full command: CREATE TABLE my (c1 INT, c2 INT, c3 INT, PRIMARY KEY
*USING* {*}SORTED{*}{*}{{*}} (c2 ASC, c1 DESC NULL FIRST))
Also let's set BTREE as default for PK without set concrete type.
was:
As of now we support choosing type just for secondary indexes, like a
_CREATE INDEX idx_name ON table *USING TREE* (column_name)_
But for PK we always create under the hood HASH index.
Let's introduce ability to choose type for PK by the analogy with a secondary
indexes;
it should be add an optional parameter *USING type* for PRIMARY KEY definition
and add ability set collation for columns including into PK)
CREATE TABLE . (..., PRIMARY KEY *[ USING SORTED | HASH ]* (column1,
column2, ... column_n)) ...)
as example full command: CREATE TABLE my (c1 INT, c2 INT, c3 INT, PRIMARY *KEY
USING* {*}SORTED{*}{*}{*} (c2 ASC, c1 DESC NULL FIRST))
Also let's set BTREE as default for PK without set concrete type.
> Sql. Support for choosing the primary key index type.
> -
>
> Key: IGNITE-21353
> URL: https://issues.apache.org/jira/browse/IGNITE-21353
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> As of now we support choosing type just for secondary indexes, like a
> _CREATE INDEX idx_name ON table *USING TREE* (column_name)_
> But for PK we always create under the hood HASH index.
> Let's introduce ability to choose type for PK by the analogy with a secondary
> indexes;
> it should be add an optional parameter *USING type* for PRIMARY KEY
> definition and add ability set collation for columns including into PK)
> CREATE TABLE . (..., PRIMARY KEY *[ USING SORTED | HASH ]* (column1,
> column2, ... column_n)) ...)
> as example full command: CREATE TABLE my (c1 INT, c2 INT, c3 INT, PRIMARY KEY
> *USING* {*}SORTED{*}{*}{{*}} (c2 ASC, c1 DESC NULL FIRST))
> Also let's set BTREE as default for PK without set concrete type.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21353) Sql. Support for choosing the primary key index type.
[
https://issues.apache.org/jira/browse/IGNITE-21353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-21353:
---
Description:
As of now we support choosing type just for secondary indexes, like a
_CREATE INDEX idx_name ON table *USING TREE* (column_name)_
But for PK we always create under the hood HASH index.
Let's introduce ability to choose type for PK by the analogy with a secondary
indexes;
it should be add an optional parameter *USING type* for PRIMARY KEY definition
and add ability set collation for columns including into PK)
CREATE TABLE . (..., PRIMARY KEY *[ USING SORTED | HASH ]* (column1,
column2, ... column_n)) ...)
as example full command: CREATE TABLE my (c1 INT, c2 INT, c3 INT, PRIMARY *KEY
USING* {*}SORTED{*}{*}{*} (c2 ASC, c1 DESC NULL FIRST))
Also let's set BTREE as default for PK without set concrete type.
was:
As of now we support choosing type just for secondary indexes, like a
_CREATE INDEX idx_name ON table *USING TREE* (column_name)_
But for PK we always create under the hood HASH index.
Let's introduce ability to choose type for PK by the analogy with a secondary
indexes;
it should be add an optional parameter *USING type* for PRIMARY KEY definition
and add ability set collation for columns including into PK)
CREATE TABLE . (..., PRIMARY KEY *[ USING BTREE | HASH ]* (column1,
column2, ... column_n)) ...)
as example full command: CREATE TABLE my (c1 INT, c2 INT, c3 INT, PRIMARY *KEY
USING TREE* (c2 ASC, c1 DESC NULL FIRST))
Also let's set BTREE as default for PK without set concrete type.
> Sql. Support for choosing the primary key index type.
> -
>
> Key: IGNITE-21353
> URL: https://issues.apache.org/jira/browse/IGNITE-21353
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> As of now we support choosing type just for secondary indexes, like a
> _CREATE INDEX idx_name ON table *USING TREE* (column_name)_
> But for PK we always create under the hood HASH index.
> Let's introduce ability to choose type for PK by the analogy with a secondary
> indexes;
> it should be add an optional parameter *USING type* for PRIMARY KEY
> definition and add ability set collation for columns including into PK)
> CREATE TABLE . (..., PRIMARY KEY *[ USING SORTED | HASH ]* (column1,
> column2, ... column_n)) ...)
> as example full command: CREATE TABLE my (c1 INT, c2 INT, c3 INT, PRIMARY
> *KEY USING* {*}SORTED{*}{*}{*} (c2 ASC, c1 DESC NULL FIRST))
> Also let's set BTREE as default for PK without set concrete type.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21353) Sql. Support for choosing the primary key index type.
[ https://issues.apache.org/jira/browse/IGNITE-21353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-21353: --- Description: As of now we support choosing type just for secondary indexes, like a _CREATE INDEX idx_name ON table *USING TREE* (column_name)_ But for PK we always create under the hood HASH index. Let's introduce ability to choose type for PK by the analogy with a secondary indexes; it should be add an optional parameter *USING type* for PRIMARY KEY definition and add ability set collation for columns including into PK) CREATE TABLE . (..., PRIMARY KEY *[ USING BTREE | HASH ]* (column1, column2, ... column_n)) ...) as example full command: CREATE TABLE my (c1 INT, c2 INT, c3 INT, PRIMARY *KEY USING TREE* (c2 ASC, c1 DESC NULL FIRST)) Also let's set BTREE as default for PK without set concrete type. was: As of now we support choosing type just for secondary indexes, like a _CREATE INDEX idx_name ON table *USING TREE* (column_name)_ But for PK we always create under the hood HASH index. Let's introduce ability to choose type for PK by the analogy with a secondary indexes; it should be add an optional parameter *USING type* for PRIMARY KEY definition and add ability set collation for columns including into PK) CREATE TABLE . PRIMARY KEY *[ USING BTREE | HASH ]* (column1, column2, ... column_n)) as example full command: CREATE TABLE my (c1 INT, c2 INT, c3 INT, PRIMARY *KEY USING TREE* (c2 ASC, c1 DESC NULL FIRST)) Also let's set BTREE as default for PK without set concrete type. > Sql. Support for choosing the primary key index type. > - > > Key: IGNITE-21353 > URL: https://issues.apache.org/jira/browse/IGNITE-21353 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > As of now we support choosing type just for secondary indexes, like a > _CREATE INDEX idx_name ON table *USING TREE* (column_name)_ > But for PK we always create under the hood HASH index. > Let's introduce ability to choose type for PK by the analogy with a secondary > indexes; > it should be add an optional parameter *USING type* for PRIMARY KEY > definition and add ability set collation for columns including into PK) > CREATE TABLE . (..., PRIMARY KEY *[ USING BTREE | HASH ]* (column1, > column2, ... column_n)) ...) > as example full command: CREATE TABLE my (c1 INT, c2 INT, c3 INT, PRIMARY > *KEY USING TREE* (c2 ASC, c1 DESC NULL FIRST)) > Also let's set BTREE as default for PK without set concrete type. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21353) Sql. Support for choosing the primary key index type.
[ https://issues.apache.org/jira/browse/IGNITE-21353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-21353: --- Description: As of now we support choosing type just for secondary indexes, like a _CREATE INDEX idx_name ON table *USING TREE* (column_name)_ But for PK we always create under the hood HASH index. Let's introduce ability to choose type for PK by the analogy with a secondary indexes; it should be add an optional parameter *USING type* for PRIMARY KEY definition and add ability set collation for columns including into PK) CREATE TABLE . PRIMARY KEY *[ USING BTREE | HASH ]* (column1, column2, ... column_n)) as example full command: CREATE TABLE my (c1 INT, c2 INT, c3 INT, PRIMARY *KEY USING TREE* (c2 ASC, c1 DESC NULL FIRST)) Also let's set BTREE as default for PK without set concrete type. was: As of now we support choosing type just for secondary indexes, like a _CREATE INDEX idx_name ON table *USING TREE* (column_name)_ But for PK we always create under the hood HASH index. Let's introduce ability to choose type for PK by the analogy with a secondary indexes; it should be add an optional parameter *USING type* for PRIMARY KEY definition CREATE TABLE . PRIMARY KEY *[ USING BTREE | HASH ]* (column1, column2, ... column_n)... Also let's set BTREE as default for PK without set concrete type. > Sql. Support for choosing the primary key index type. > - > > Key: IGNITE-21353 > URL: https://issues.apache.org/jira/browse/IGNITE-21353 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > As of now we support choosing type just for secondary indexes, like a > _CREATE INDEX idx_name ON table *USING TREE* (column_name)_ > But for PK we always create under the hood HASH index. > Let's introduce ability to choose type for PK by the analogy with a secondary > indexes; > it should be add an optional parameter *USING type* for PRIMARY KEY > definition and add ability set collation for columns including into PK) > CREATE TABLE . PRIMARY KEY *[ USING BTREE | HASH ]* (column1, column2, > ... column_n)) > as example full command: CREATE TABLE my (c1 INT, c2 INT, c3 INT, PRIMARY > *KEY USING TREE* (c2 ASC, c1 DESC NULL FIRST)) > Also let's set BTREE as default for PK without set concrete type. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21353) Sql. Support for choosing the primary key index type.
Yury Gerzhedovich created IGNITE-21353: -- Summary: Sql. Support for choosing the primary key index type. Key: IGNITE-21353 URL: https://issues.apache.org/jira/browse/IGNITE-21353 Project: Ignite Issue Type: Improvement Components: sql Reporter: Yury Gerzhedovich As of now we support choosing type just for secondary indexes, like a _CREATE INDEX idx_name ON table *USING TREE* (column_name)_ But for PK we always create under the hood HASH index. Let's introduce ability to choose type for PK by the analogy with a secondary indexes; it should be add an optional parameter *USING type* for PRIMARY KEY definition CREATE TABLE . PRIMARY KEY *[ USING BTREE | HASH ]* (column1, column2, ... column_n)... Also let's set BTREE as default for PK without set concrete type. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21353) Sql. Support for choosing the primary key index type.
[ https://issues.apache.org/jira/browse/IGNITE-21353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-21353: --- Labels: ignite-3 (was: ) > Sql. Support for choosing the primary key index type. > - > > Key: IGNITE-21353 > URL: https://issues.apache.org/jira/browse/IGNITE-21353 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > As of now we support choosing type just for secondary indexes, like a > _CREATE INDEX idx_name ON table *USING TREE* (column_name)_ > But for PK we always create under the hood HASH index. > Let's introduce ability to choose type for PK by the analogy with a secondary > indexes; > it should be add an optional parameter *USING type* for PRIMARY KEY definition > CREATE TABLE . PRIMARY KEY *[ USING BTREE | HASH ]* (column1, column2, > ... column_n)... > Also let's set BTREE as default for PK without set concrete type. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17703) Extaract hardcoded constants to configuration in sql-engine module
[ https://issues.apache.org/jira/browse/IGNITE-17703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-17703: --- Description: We have many hardcoded constants in sql-engine module. So it can't be configure by user. Let's move the following to configuration: ||Constant||Configuration path||Type|| |PrepareServiceImpl#DEFAULT_PLANNER_TIMEOUT|sql.planner.maxPlanningTime|Distributed| |PrepareServiceImpl#THREAD_COUNT|sql.planner.threadCount|Local| |SqlQueryProcessor#PLAN_CACHE_SIZE|sql.planner.estimatedNumberOfQueries|Distributed| |QueryTaskExecutorImpl.stripedThreadPoolExecutor|sql.execution.threadCount|Local| | | | | was: We have many hardcoded constants in sql-engine module. So it can't be configure by user. Let's move the following to configuration: ||Constant||Configuration path||Type|| |PrepareServiceImpl#DEFAULT_PLANNER_TIMEOUT|sql.planner.maxPlanningTime|Distributed| |PrepareServiceImpl#THREAD_COUNT|sql.planner.threadCount|Local| |SqlQueryProcessor#PLAN_CACHE_SIZE|sql.planner.estimatedNumberOfQueries|Distributed| |QueryTaskExecutorImpl.stripedThreadPoolExecutor|sql.execution.concurrencyLevel|Local| | | | | > Extaract hardcoded constants to configuration in sql-engine module > -- > > Key: IGNITE-17703 > URL: https://issues.apache.org/jira/browse/IGNITE-17703 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: ignite-3, tech-debt > Time Spent: 40m > Remaining Estimate: 0h > > We have many hardcoded constants in sql-engine module. So it can't be > configure by user. > Let's move the following to configuration: > ||Constant||Configuration path||Type|| > |PrepareServiceImpl#DEFAULT_PLANNER_TIMEOUT|sql.planner.maxPlanningTime|Distributed| > |PrepareServiceImpl#THREAD_COUNT|sql.planner.threadCount|Local| > |SqlQueryProcessor#PLAN_CACHE_SIZE|sql.planner.estimatedNumberOfQueries|Distributed| > |QueryTaskExecutorImpl.stripedThreadPoolExecutor|sql.execution.threadCount|Local| > | | | | > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21341) Sql. Optimize way to execute insert
[ https://issues.apache.org/jira/browse/IGNITE-21341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-21341: --- Labels: ignite-3 (was: ) > Sql. Optimize way to execute insert > --- > > Key: IGNITE-21341 > URL: https://issues.apache.org/jira/browse/IGNITE-21341 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > As of now we use common approach for all execution queries. > Obviously, we can use simple KV put for simple insert statement. Let's > analyze the AST to identify such simple insert and execute it in an > optimized way, avoiding the common complex path. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21341) Sql. Optimize way to execute insert
[ https://issues.apache.org/jira/browse/IGNITE-21341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich reassigned IGNITE-21341: -- Assignee: Yury Gerzhedovich > Sql. Optimize way to execute insert > --- > > Key: IGNITE-21341 > URL: https://issues.apache.org/jira/browse/IGNITE-21341 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > > As of now we use common approach for all execution queries. > Obviously, we can use simple KV put for simple insert statement. Let's > analyze the AST to identify such simple insert and execute it in an > optimized way, avoiding the common complex path. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21341) Sql. Optimize way to execute insert
Yury Gerzhedovich created IGNITE-21341: -- Summary: Sql. Optimize way to execute insert Key: IGNITE-21341 URL: https://issues.apache.org/jira/browse/IGNITE-21341 Project: Ignite Issue Type: Improvement Components: sql Reporter: Yury Gerzhedovich As of now we use common approach for all execution queries. Obviously, we can use simple KV put for simple insert statement. Let's analyze the AST to identify such simple insert and execute it in an optimized way, avoiding the common complex path. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21306) Sql. Optimize way to execute simple select
[ https://issues.apache.org/jira/browse/IGNITE-21306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-21306: --- Description: As of now we use common approach for all execution queries. Obviously, we can use simple KV get when fetching by PK. Let's analyze the AST to identify such a simple request and execute it in an optimized way, avoiding the common complex path was: As of now we use common approach for all execution queries. Obviously, we can use simple KV put /get when fetching by PK. Let's analyze the AST to identify such a simple request and execute it in an optimized way, avoiding the common complex path > Sql. Optimize way to execute simple select > -- > > Key: IGNITE-21306 > URL: https://issues.apache.org/jira/browse/IGNITE-21306 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > As of now we use common approach for all execution queries. > Obviously, we can use simple KV get when fetching by PK. Let's analyze the > AST to identify such a simple request and execute it in an optimized way, > avoiding the common complex path -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21306) Sql. Optimize way to execute simple select
[ https://issues.apache.org/jira/browse/IGNITE-21306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-21306: --- Summary: Sql. Optimize way to execute simple select (was: Sql. Optimize way to execute simple select and insert) > Sql. Optimize way to execute simple select > -- > > Key: IGNITE-21306 > URL: https://issues.apache.org/jira/browse/IGNITE-21306 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > As of now we use common approach for all execution queries. > Obviously, we can use simple KV put /get when fetching by PK. Let's analyze > the AST to identify such a simple request and execute it in an optimized way, > avoiding the common complex path -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17703) Extaract hardcoded constants to configuration in sql-engine module
[ https://issues.apache.org/jira/browse/IGNITE-17703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-17703: --- Description: We have many hardcoded constants in sql-engine module. So it can't be configure by user. Let's move the following to configuration: ||Constant||Configuration path||Type|| |PrepareServiceImpl#DEFAULT_PLANNER_TIMEOUT|sql.planner.maxPlanningTime|Distributed| |PrepareServiceImpl#THREAD_COUNT|sql.planner.threadCount|Local| |SqlQueryProcessor#PLAN_CACHE_SIZE|sql.planner.estimatedNumberOfQueries|Distributed| |QueryTaskExecutorImpl.stripedThreadPoolExecutor|sql.execution.concurrencyLevel|Local| | | | | was: We have many hardcoded constants in sql-engine module. So it can't be configure by user. Let's move the following to configuration: ||Constant||Configuration path||Type|| |PrepareServiceImpl#DEFAULT_PLANNER_TIMEOUT|sql.planner.maxPlanningTime|Distributed| |PrepareServiceImpl#THREAD_COUNT|sql.planner.threadCount|Local| |SqlQueryProcessor#PLAN_CACHE_SIZE|sql.planner.estimatedNumberOfQueries|Distributed| |QueryTaskExecutorImpl.stripedThreadPoolExecutor|sql.execution.concurrencyLevel|Local| | | | | > Extaract hardcoded constants to configuration in sql-engine module > -- > > Key: IGNITE-17703 > URL: https://issues.apache.org/jira/browse/IGNITE-17703 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: ignite-3, tech-debt > > We have many hardcoded constants in sql-engine module. So it can't be > configure by user. > Let's move the following to configuration: > ||Constant||Configuration path||Type|| > |PrepareServiceImpl#DEFAULT_PLANNER_TIMEOUT|sql.planner.maxPlanningTime|Distributed| > |PrepareServiceImpl#THREAD_COUNT|sql.planner.threadCount|Local| > |SqlQueryProcessor#PLAN_CACHE_SIZE|sql.planner.estimatedNumberOfQueries|Distributed| > |QueryTaskExecutorImpl.stripedThreadPoolExecutor|sql.execution.concurrencyLevel|Local| > | | | | > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21287) Sql. LogicalOrToUnionRule may hang
[ https://issues.apache.org/jira/browse/IGNITE-21287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-21287: --- Summary: Sql. LogicalOrToUnionRule may hang (was: Sql. LogicalOrToUnionRule may hand) > Sql. LogicalOrToUnionRule may hang > -- > > Key: IGNITE-21287 > URL: https://issues.apache.org/jira/browse/IGNITE-21287 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > LogicalOrToUnionRule may hand in case of huge conditions. Let's investigate > possible solutions under this ticket and uncomment the rule. > To reproduce the issue, try to uncomment the rule and run q19 from TPC-H > suite after IGNITE-20880. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17703) Extaract hardcoded constants to configuration in sql-engine module
[ https://issues.apache.org/jira/browse/IGNITE-17703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-17703: --- Description: We have many hardcoded constants in sql-engine module. So it can't be configure by user. Let's move the following to configuration: ||Constant||Configuration path||Type|| |PrepareServiceImpl#DEFAULT_PLANNER_TIMEOUT|sql.planner.maxPlanningTime|Distributed| |PrepareServiceImpl#THREAD_COUNT|sql.planner.threadCount|Local| |SqlQueryProcessor#PLAN_CACHE_SIZE|sql.planner.estimatedNumberOfQueries|Distributed| |QueryTaskExecutorImpl.stripedThreadPoolExecutor|sql.execution.concurrencyLevel|Local| | | | | was: We have many hardcoded constants in sql-engine module. So it can't be configure by user. Let's move the following to configuration: ||Constant||Configuration path|| |PrepareServiceImpl#DEFAULT_PLANNER_TIMEOUT|sql.planner.maxPlanningTime| |PrepareServiceImpl#THREAD_COUNT|sql.planner.threadCount| |SqlQueryProcessor#PLAN_CACHE_SIZE|sql.planner.estimatedNumberOfQueries| |QueryTaskExecutorImpl.stripedThreadPoolExecutor|sql.execution.concurrencyLevel| | | | > Extaract hardcoded constants to configuration in sql-engine module > -- > > Key: IGNITE-17703 > URL: https://issues.apache.org/jira/browse/IGNITE-17703 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: ignite-3, tech-debt > > We have many hardcoded constants in sql-engine module. So it can't be > configure by user. > Let's move the following to configuration: > ||Constant||Configuration path||Type|| > |PrepareServiceImpl#DEFAULT_PLANNER_TIMEOUT|sql.planner.maxPlanningTime|Distributed| > |PrepareServiceImpl#THREAD_COUNT|sql.planner.threadCount|Local| > |SqlQueryProcessor#PLAN_CACHE_SIZE|sql.planner.estimatedNumberOfQueries|Distributed| > |QueryTaskExecutorImpl.stripedThreadPoolExecutor|sql.execution.concurrencyLevel|Local| > | | | | -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20812) Sql. Performance of a queries affected by number of partitions
[ https://issues.apache.org/jira/browse/IGNITE-20812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-20812: --- Epic Link: IGNITE-21312 > Sql. Performance of a queries affected by number of partitions > -- > > Key: IGNITE-20812 > URL: https://issues.apache.org/jira/browse/IGNITE-20812 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > Performance of INSERT and SELECT by primary key queries is affected by number > of partitions in the table. Most probably, the reason is a lack of partition > pruning in sql engine. > Let's investigate and fix the problem. > Here is a result of local (on my laptop; 2,6 GHz 6-Core Intel Core i7 32GB > RAM) benchmark: > ||Benchmark||(clusterSize)||(fsync)||(partitionCount)||Mode||Cnt||Score||Error||Units|| > |InsertBenchmark.sqlInsert|1|false|1|avgt|20|0.643|± 0.069|ms/op| > |InsertBenchmark.sqlInsert|1|false|5|avgt|20|0.756|± 0.049|ms/op| > |InsertBenchmark.sqlInsert|1|false|25|avgt|20|1.114|± 0.093|ms/op| > |SelectBenchmark.sqlGet|1|false|1|avgt|20|203.432|± 16.617|us/op| > |SelectBenchmark.sqlGet|1|false|5|avgt|20|320.383|± 22.086|us/op| > |SelectBenchmark.sqlGet|1|false|25|avgt|20|794.232|± 49.473|us/op| -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20495) Sql. Provide IgniteTableModify with source id
[
https://issues.apache.org/jira/browse/IGNITE-20495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-20495:
---
Description:
Currently, IgniteTableModify doesn't implement interface SourceAwareIgniteRel,
and, as a result, is not being assigned its own source id, although requires to
be mapped on particular set of nodes with regards to the distribution of the
table it modifies.
To fully integrate TableModify into mapping process, let's make it implement
SourceAwareIgniteRel. This id should be used during mapping phase to create
colocation group properly, and inside execution to acquire assignments. See
usages of {{UpdatableTableImpl#MODIFY_NODE_SOURCE_ID}} to find all places that
should be changed.
was:
Currently, IgniteTableModify doesn't implement interface SourceAwareIgniteRel,
and, as a result, is not being assigned its own source id, although requires to
be mapped on particular set of nodes with regards to the distribution of the
table it modifies.
To fully integrate TableModify into mapping process, let's make it implement
SourceAwareIgniteRel. This id should be used during mapping phase to create
colocation group properly, and inside execution to acquire assignments. See
usages of {{UpdatableTableImpl#MODIFY_NODE_SOURCE_ID}} to find all places that
should be changed.
> Sql. Provide IgniteTableModify with source id
> --
>
> Key: IGNITE-20495
> URL: https://issues.apache.org/jira/browse/IGNITE-20495
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
>
> Currently, IgniteTableModify doesn't implement interface
> SourceAwareIgniteRel, and, as a result, is not being assigned its own source
> id, although requires to be mapped on particular set of nodes with regards to
> the distribution of the table it modifies.
> To fully integrate TableModify into mapping process, let's make it implement
> SourceAwareIgniteRel. This id should be used during mapping phase to create
> colocation group properly, and inside execution to acquire assignments. See
> usages of {{UpdatableTableImpl#MODIFY_NODE_SOURCE_ID}} to find all places
> that should be changed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21310) Sql. Partition pruning. Introduce partition provider
[
https://issues.apache.org/jira/browse/IGNITE-21310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-21310:
---
Description:
In order to implement partition pruning, we need a component that will return
partition id by given colocation keys' values. We already have
HashCalculator+ColocationUtils to calculate colocation hash and
TypesAwareHashFunction which does pretty match the same thing but for sql.
My proposal is to introduce component that will consume values similarly to
HashCalculator but will return particular partition id with regard to table's
column types and number of its partitions.
As part of this ticket, let's integrate new component into
{{org.apache.ignite.internal.sql.engine.trait.Partitioned}} destination
function.
was:
In order to implement partition pruning, we need a component that will return
partition id by given colocation keys' values. We already have
HashCalculator+ColocationUtils to calculate colocation hash and
TypesAwareHashFunction which does pretty match the same thing but for sql.
My proposal is to introduce component that will consume values similarly to
HashCalculator but will return particular partition id with regard to table's
column types and number of its partitions.
As part of this ticket, let's integrate new component into
{{org.apache.ignite.internal.sql.engine.trait.Partitioned}} destination
function.
> Sql. Partition pruning. Introduce partition provider
>
>
> Key: IGNITE-21310
> URL: https://issues.apache.org/jira/browse/IGNITE-21310
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
>
> In order to implement partition pruning, we need a component that will return
> partition id by given colocation keys' values. We already have
> HashCalculator+ColocationUtils to calculate colocation hash and
> TypesAwareHashFunction which does pretty match the same thing but for sql.
> My proposal is to introduce component that will consume values similarly to
> HashCalculator but will return particular partition id with regard to table's
> column types and number of its partitions.
> As part of this ticket, let's integrate new component into
> {{org.apache.ignite.internal.sql.engine.trait.Partitioned}} destination
> function.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21277) Sql. Partition pruning. Port partitionExtractor from AI2.
[
https://issues.apache.org/jira/browse/IGNITE-21277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-21277:
---
Description:
In order to prune unnecessary partitions we need to obtain information that
includes possible "values" of colocation key columns from filter expressions
for every scan operators prior to statement execution. This can be accomplished
by traversing an expression tree of scan's filter and collecting expressions
with colocation key columns (this data is called partition pruning metadata for
simplicity).
1. Implement a component that takes a physical plan and analyses filter
expressions of every scan operator and creates (if possible) an expression that
includes all colocated columns. (The PartitionExtractor from patch
(https://github.com/apache/ignite/pull/10928/files) can be used a reference
implementation).
Expression types to analyze:
* AND
* EQUALS
* IS_FALSE
* IS_NOT_DISTINCT_FROM
* IS_NOT_FALSE
* IS_NOT_TRUE
* IS_TRUE
* NOT
* OR
* SEARCH (operation that tests whether a value is included in a certain range)
2. Update QueryPlan to include partition pruning metadata for every scan
operator (source_id = ).
Basic examples:
{code:java}
Statement:
SELECT * FROM t WHERE pk = 7 OR pk = 42
Partition metadata:
t's source_id = [pk=7 || pk = 42] // Assuming colocation key is equal to
primary key, || denotes OR operation
Statement:
SELECT * FROM t WHERE pk = 7 OR col1 = 1
Partition metadata: [] // Empty, because col1 is not part of a colocation key.
Statement:
SELECT * FROM t_colo_key1_colo_key2 WHERE colo_key1= 42
Partition metadata: [] // Empty, because colo_key2 is missing
{code}
—
*Additional examples - partition pruning is possible*
Dynamic parameters:
{code:java}
SELECT * FROM t WHERE pk = ?1
Partition pruning metadata: t = [ pk = ?1 ]
{code}
Colocation columns reside inside a nested expression:
{code:java}
SELECT * FROM t WHERE col1 = col2 AND (col2 = 100 AND pk = 2)
Partition pruning metadata: t = [ pk = 2 ]
{code}
Multiple keys:
{code:java}
SELECT * FROM t WHERE col_c1 = 1 AND col_c2 = 2
Partition pruning metadata: t = [ (col_c1 = 1, col_c2 = 2) ]
{code}
Complex expression with multiple keys:
{code:java}
SELECT * FROM t WHERE (col_col1 = 100 and col_col2 = 4) OR (col_col1 = 4 and
col_col2 = 100)
Partition pruning metadata: t = [ (col_col1 = 100, col_col2 = 4) || (col_col1 =
4, col_col2 = 100) ]
{code}
Multiple tables, assuming that filter b_id = 42 is pushed into scan b, because
a_id = b_id:
{code:java}
SELECT * FROM a JOIN b WHERE a_id = b_id AND a_id = 42
Partition pruning metadata: a= [ a_id=42 ], b=[ b_id=42 ]
{code}
---
*Additional examples - partition pruning is not possible*
Columns named col* are not part of colocation key:
{code:java}
SELECT * FROM t WHERE col1 = 10
// Filter does not use colocation key columns.
Partition pruning metadata: []
{code}
{code:java}
SELECT * FROM t WHERE col1 = col2 OR pk = 42
// We need to scan all partitions to figure out which tuples have ‘col1 = col2’
Partition pruning metadata: []
{code}
{code:java}
SELECT * FROM t WHERE col_col1 = 10 AND col_col2 OR col_col1 = 42
// Although first expression uses all colocation key columns the second one
only uses some.
Partition pruning metadata: []
{code}
{code:java}
SELECT * FROM t WHERE col_c1 = 1 OR col_c2 = 2
// We need to scan all partitions to figure out which tuples have col_c1 = 1 OR
col_c2 = 2.
Partition pruning metadata: []
{code}
{code:java}
SELECT * FROM t WHERE col_col1 = col_col2 OR col_col2 = 42
// We need to scan all partitions to figure out which tuples have ‘col_col1 =
col_col2’
Partition pruning metadata: []
{code}
was:
In order to prune unnecessary partitions we need to obtain information that
includes possible "values" of colocation key columns from filter expressions
for every scan operators prior to statement execution. This can be accomplished
by traversing an expression tree of scan's filter and collecting expressions
with colocation key columns (this data is called partition pruning metadata for
simplicity).
1. Implement a component that takes a physical plan and analyses filter
expressions of every scan operator and creates (if possible) an expression that
includes all colocated columns. (The PartitionExtractor from patch
(https://github.com/apache/ignite/pull/10928/files) can be used a reference
implementation).
Expression types to analyze:
* AND
* EQUALS
* IS_FALSE
* IS_NOT_DISTINCT_FROM
* IS_NOT_FALSE
* IS_NOT_TRUE
* IS_TRUE
* NOT
* OR
* SEARCH (operation that tests whether a value is included in a certain range)
2. Update QueryPlan to include partition pruning metadata for every scan
operator (source_id = ).
Basic examples:
{code:java}
Statement:
SELECT * FROM t WHERE pk = 7 OR pk = 42
Partition metadata:
t's source_id = [pk=7 || pk = 42] // Assuming colocation key is
[jira] [Updated] (IGNITE-21281) Sql. Partition pruning. Integrate static partition pruning into MODIFY statements execution pipeline.
[ https://issues.apache.org/jira/browse/IGNITE-21281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-21281: --- Description: Given partition pruning information for each scan operator of a QueryPlan, we can evaluate a partition pruning predicate against statement's execution context to prune partitions that modify operations won't touch. 1. Traverse fragment tree to analyze inputs of DML operations: - If Modify operation accepts Scan operation as an input (UPDATE), we do not need to do anything when both operations are collocated and this case is covered by https://issues.apache.org/jira/browse/IGNITE-21279). - For operations that accept INSERT/ MERGE, we need to consider values of colocation key columns of both Value and Projection operators, since SQL's VALUES accepts DEFAULT expression. 2. Use affinity function and statement's execution context to evaluate partition pruning predicates for each scan operator, so enlist is only called for partitions that should be scanned/modified. After this issue is resolved, partition pruning should work for INSERT, UPDATE, MERGE, and DELETE statements. was: Given partition pruning information for each scan operator of a QueryPlan, we can evaluate a partition pruning predicate against statement's execution context to prune partitions that modify operations won't touch. 1. Traverse fragment tree to analyze inputs of DML operations: - If Modify operation accepts Scan operation as an input (UPDATE), we do not need to do anything when both operations are collocated and this case is covered by https://issues.apache.org/jira/browse/IGNITE-21279). - For operations that accept INSERT/ MERGE, we need to consider values of colocation key columns of both Value and Projection operators, since SQL's VALUES accepts DEFAULT expression. 2. Use affinity function and statement's execution context to evaluate partition pruning predicates for each scan operator, so enlist is only called for partitions that should be scanned/modified. After this issue is resolved, partition pruning should work for INSERT, UPDATE, MERGE, and DELETE statements. > Sql. Partition pruning. Integrate static partition pruning into MODIFY > statements execution pipeline. > - > > Key: IGNITE-21281 > URL: https://issues.apache.org/jira/browse/IGNITE-21281 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta2 >Reporter: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > > Given partition pruning information for each scan operator of a QueryPlan, we > can evaluate a partition pruning predicate against statement's execution > context to prune partitions that modify operations won't touch. > 1. Traverse fragment tree to analyze inputs of DML operations: > - If Modify operation accepts Scan operation as an input (UPDATE), we do > not need to do anything when both operations are collocated and this case is > covered by https://issues.apache.org/jira/browse/IGNITE-21279). > - For operations that accept INSERT/ MERGE, we need to consider values of > colocation key columns of both Value and Projection operators, since SQL's > VALUES accepts DEFAULT expression. > 2. Use affinity function and statement's execution context to evaluate > partition pruning predicates for each scan operator, so enlist is only called > for partitions that should be scanned/modified. > After this issue is resolved, partition pruning should work for INSERT, > UPDATE, MERGE, and DELETE statements. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21311) Sql. Partition pruning. Introduce pruning for correlated scans
[ https://issues.apache.org/jira/browse/IGNITE-21311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-21311: --- Description: Apart of static pruning made on preparation step, we may also introduce dynamic pruning for correlated scans. In case of correlated join, a predicate on the right shoulder should be evaluated based on the context provided from the left shoulder. This context is not known until runtime, those partitions are not trimmed on preparation step. However, this very case doesn't differ match from the static pruning: the only difference here is a time when pruning should be applied. In order to support dynamic pruning, we should save pruning meta during planning phase in a scan node. Later, in runtime, we should evaluate pruning function in order to derive partitions satisfying the predicate. Those partitions should be used to do a lookup into a table. was: Apart of static pruning made on preparation step, we may also introduce dynamic pruning for correlated scans. In case of correlated join, a predicate on the right shoulder should be evaluated based on the context provided from the left shoulder. This context is not known until runtime, those partitions are not trimmed on preparation step. However, this very case doesn't differ match from the static pruning: the only difference here is a time when pruning should be applied. In order to support dynamic pruning, we should save pruning meta during planning phase in a scan node. Later, in runtime, we should evaluate pruning function in order to derive partitions satisfying the predicate. Those partitions should be used to do a lookup into a table. > Sql. Partition pruning. Introduce pruning for correlated scans > -- > > Key: IGNITE-21311 > URL: https://issues.apache.org/jira/browse/IGNITE-21311 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > Apart of static pruning made on preparation step, we may also introduce > dynamic pruning for correlated scans. > In case of correlated join, a predicate on the right shoulder should be > evaluated based on the context provided from the left shoulder. This context > is not known until runtime, those partitions are not trimmed on preparation > step. However, this very case doesn't differ match from the static pruning: > the only difference here is a time when pruning should be applied. > In order to support dynamic pruning, we should save pruning meta during > planning phase in a scan node. Later, in runtime, we should evaluate pruning > function in order to derive partitions satisfying the predicate. Those > partitions should be used to do a lookup into a table. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21279) Sql. Partition pruning. Integrate static partition pruning into READ statements execution pipeline
[ https://issues.apache.org/jira/browse/IGNITE-21279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-21279: --- Description: Given partition pruning information for each scan operator of a QueryPlan, we can evaluate a partition pruning predicate against statement's execution context to prune partitions that scan operations won't touch. 1. Use affinity function and statement's execution context to evaluate partition pruning predicates for each scan operator, so enlist is only called for partitions that should be scanned. 2. Support table scans, and index scans. After this issue is resolved, partition pruning should work for SELECT queries. was: Given partition pruning information for each scan operator of a QueryPlan, we can evaluate a partition pruning predicate against statement's execution context to prune partitions that scan operations won't touch. 1. Use affinity function and statement's execution context to evaluate partition pruning predicates for each scan operator, so enlist is only called for partitions that should be scanned. 2. Support table scans, system view scans, and index scans. After this issue is resolved, partition pruning should work for SELECT queries. > Sql. Partition pruning. Integrate static partition pruning into READ > statements execution pipeline > -- > > Key: IGNITE-21279 > URL: https://issues.apache.org/jira/browse/IGNITE-21279 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta2 >Reporter: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > > Given partition pruning information for each scan operator of a QueryPlan, we > can evaluate a partition pruning predicate against statement's execution > context to prune partitions that scan operations won't touch. > 1. Use affinity function and statement's execution context to evaluate > partition pruning predicates for each scan operator, so enlist is only called > for partitions that should be scanned. > 2. Support table scans, and index scans. > After this issue is resolved, partition pruning should work for SELECT > queries. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20495) Sql. Provide IgniteTableModify with source id
[
https://issues.apache.org/jira/browse/IGNITE-20495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-20495:
---
Description:
Currently, IgniteTableModify doesn't implement interface SourceAwareIgniteRel,
and, as a result, is not being assigned its own source id, although requires to
be mapped on particular set of nodes with regards to the distribution of the
table it modifies.
To fully integrate TableModify into mapping process, let's make it implement
SourceAwareIgniteRel. This id should be used during mapping phase to create
colocation group properly, and inside execution to acquire assignments. See
usages of {{UpdatableTableImpl#MODIFY_NODE_SOURCE_ID}} to find all places that
should be changed.
was:
Currently, IgniteTableModify doesn't implement interface SourceAwareIgniteRel,
and, as a result, is not being assigned its own source id, although requires to
be mapped on particular set of nodes with regards to the distribution of the
table it modifies.
To fully integrate TableModify into mapping process, let's make it implement
SourceAwareIgniteRel. This id should be used during mapping phase to create
colocation group properly, and inside execution to acquire assignments. See
usages of {{UpdatableTableImpl#MODIFY_NODE_SOURCE_ID}} to find all places that
should be changed.
> Sql. Provide IgniteTableModify with source id
> --
>
> Key: IGNITE-20495
> URL: https://issues.apache.org/jira/browse/IGNITE-20495
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
>
> Currently, IgniteTableModify doesn't implement interface
> SourceAwareIgniteRel, and, as a result, is not being assigned its own source
> id, although requires to be mapped on particular set of nodes with regards to
> the distribution of the table it modifies.
> To fully integrate TableModify into mapping process, let's make it implement
> SourceAwareIgniteRel. This id should be used during mapping phase to create
> colocation group properly, and inside execution to acquire assignments. See
> usages of {{UpdatableTableImpl#MODIFY_NODE_SOURCE_ID}} to find all places
> that should be changed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20495) Sql. Provide IgniteTableModify with source id
[
https://issues.apache.org/jira/browse/IGNITE-20495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-20495:
---
Epic Link: IGNITE-21312
> Sql. Provide IgniteTableModify with source id
> --
>
> Key: IGNITE-20495
> URL: https://issues.apache.org/jira/browse/IGNITE-20495
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
>
> Currently, IgniteTableModify doesn't implement interface
> SourceAwareIgniteRel, and, as a result, is not being assigned its own source
> id, although requires to be mapped on particular set of nodes with regards to
> the distribution of the table it modifies.
> To fully integrate TableModify into mapping process, let's make it implement
> SourceAwareIgniteRel. This id should be used during mapping phase to create
> colocation group properly, and inside execution to acquire assignments. See
> usages of {{UpdatableTableImpl#MODIFY_NODE_SOURCE_ID}} to find all places
> that should be changed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21306) Sql. Optimize way to execute simple select and insert
Yury Gerzhedovich created IGNITE-21306: -- Summary: Sql. Optimize way to execute simple select and insert Key: IGNITE-21306 URL: https://issues.apache.org/jira/browse/IGNITE-21306 Project: Ignite Issue Type: Improvement Components: sql Reporter: Yury Gerzhedovich As of now we use common approach for all execution queries. Obviously, we can use simple KV put /get when fetching by PK. Let's analyze the AST to identify such a simple request and execute it in an optimized way, avoiding the common complex path -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21134) Sql. UPPER, LOWER and SUBSTRING functions must support NULL values
[
https://issues.apache.org/jira/browse/IGNITE-21134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807708#comment-17807708
]
Yury Gerzhedovich commented on IGNITE-21134:
[~zstan], LGTM
> Sql. UPPER, LOWER and SUBSTRING functions must support NULL values
> --
>
> Key: IGNITE-21134
> URL: https://issues.apache.org/jira/browse/IGNITE-21134
> Project: Ignite
> Issue Type: Bug
> Components: clients, sql
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As described in ANSI99 specification, functions UPPER and LOWER must return
> NULL values for NULL argument:
>
> ??5) If is specified, then:??
> ?? .. b) if S is the null value, then the result of the is the null
> value.??
> In the recent AI3 (commit c2ac5850973ae3bfd44b06fc6e3b5880f9f292f1) an error
> is shown instead:
> {code:sql}
> sql-cli> SELECT UPPER(NULL);
> Unknown error
> Unsupported Column type NULL
> sql-cli> SELECT LOWER(NULL);
> Unknown error
> Unsupported Column type NULL
> sql-cli> SELECT SUBSTRING(NULL FROM 1 FOR 2);
> Unknown error
> Unsupported Column type NULL{code}
> {*}NOTE{*}: Most probably, it may be caused by client module, not sql module
> because a text of error is located in client-common module:
> {code:java}
> $ grep -r 'Unsupported Column type' modules/*/src/main
> modules/client-common/src/main/java/org/apache/ignite/internal/jdbc/JdbcConverterUtils.java:
> throw new IllegalArgumentException("Unsupported Column type "
> + columnType);
> {code}
> And when I add the following assertion to some test in ItFunctionsTest, it
> passes:
> {code:java}
> assertQuery("SELECT LOWER(NULL)").returns(null).check();
> {code}
> Previous AI3 versions allowed using NULL values in UPPER and LOWER functions,
> hence it's a degradation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21131) Calcite engine. OR operator with dynamic parameters can't be used for index scans
[
https://issues.apache.org/jira/browse/IGNITE-21131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-21131:
---
Labels: calcite calcite3-required ise (was: calcite ise)
> Calcite engine. OR operator with dynamic parameters can't be used for index
> scans
> -
>
> Key: IGNITE-21131
> URL: https://issues.apache.org/jira/browse/IGNITE-21131
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, calcite3-required, ise
> Fix For: 2.17
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Calcite can compose OR operator with literals to SEARCH/SARG, and SEARCH/SARG
> can be used for index scans. But we can't do this for OR operator with
> dynamic parameters.
> For example expression {{a IN (1, 2, 3)}} can be converted to {{a = 1 OR a =
> 2 OR a = 3}} and after that can be converted to {{SEARCH(a, SARG(1, 2, 3))}},
> but expression {{a IN (?, ?, ?)}} can be converted only to {{a = ? OR a = ?
> OR a = ?}} and can't be used for index scan.
> To fix this issue we can create ranges from dynamic parameters during
> planning, sort and remove intersections from these ranges in runtime.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21171) Calcite engine. Field nullability flag lost for data types with precession or scale
[
https://issues.apache.org/jira/browse/IGNITE-21171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807192#comment-17807192
]
Yury Gerzhedovich commented on IGNITE-21171:
[~alex_pl] Why is it the issue? By default column can contains null value.
> Calcite engine. Field nullability flag lost for data types with precession or
> scale
> ---
>
> Key: IGNITE-21171
> URL: https://issues.apache.org/jira/browse/IGNITE-21171
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ise
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Reproducer:
> {code:java}
> CREATE TABLE test(id INT PRIMARY KEY, val DECIMAL(10,2));
> INSERT INTO test(id, val) VALUES (0, NULL); {code}
> Fail with: {{Column 'VAL' has no default value and does not allow NULLs}}
> But it works if {{val}} data type is {{DECIMAL}} or {{INT}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17703) Extaract hardcoded constants to configuration in sql-engine module
[ https://issues.apache.org/jira/browse/IGNITE-17703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich reassigned IGNITE-17703: -- Assignee: Yury Gerzhedovich > Extaract hardcoded constants to configuration in sql-engine module > -- > > Key: IGNITE-17703 > URL: https://issues.apache.org/jira/browse/IGNITE-17703 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: ignite-3, tech-debt > > We have many hardcoded constants in sql-engine module. So it can't be > configure by user. > Let's move the following to configuration: > ||Constant||Configuration path|| > |PrepareServiceImpl#DEFAULT_PLANNER_TIMEOUT|sql.planner.maxPlanningTime| > |PrepareServiceImpl#THREAD_COUNT|sql.planner.threadCount| > |SqlQueryProcessor#PLAN_CACHE_SIZE|sql.planner.estimatedNumberOfQueries| > |QueryTaskExecutorImpl.stripedThreadPoolExecutor|sql.execution.concurrencyLevel| > | | | -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21203) flaky org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession
[ https://issues.apache.org/jira/browse/IGNITE-21203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17805127#comment-17805127 ] Yury Gerzhedovich commented on IGNITE-21203: [~korlov] LGTM, thanks > flaky org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession > -- > > Key: IGNITE-21203 > URL: https://issues.apache.org/jira/browse/IGNITE-21203 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > The test > org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession is > flacky due to org.apache.ignite.internal.sql.api.SessionImpl#close relies on > the fact that the returned CompletableFuture will be complited only after all > resources have been closed. However, > org.apache.ignite.internal.sql.api.SessionImpl#closeAsync returns a always > ready facke CompletableFuture. > The closeInternal() method needs to be slightly reworked to return a real > CompletableFuture and start using the return value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21228) Data not available thtough JDBC after inserting using KV for a while
[ https://issues.apache.org/jira/browse/IGNITE-21228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17805081#comment-17805081 ] Yury Gerzhedovich commented on IGNITE-21228: [~Berkov] could you confirm that the rows available through java API in the same time? > Data not available thtough JDBC after inserting using KV for a while > > > Key: IGNITE-21228 > URL: https://issues.apache.org/jira/browse/IGNITE-21228 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > > # Create table using java API > # Insert 100 rows using sync KV java API > # Connect using JDBC and try to select inserted data > Expected result: all rows available > Actual result: no rows available for a few hundreds of milliseconds > (700-1000ms on my laptop). > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21203) flaky org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession
Yury Gerzhedovich created IGNITE-21203: -- Summary: flaky org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession Key: IGNITE-21203 URL: https://issues.apache.org/jira/browse/IGNITE-21203 Project: Ignite Issue Type: Improvement Components: sql Reporter: Yury Gerzhedovich The test org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession is flacky due to org.apache.ignite.internal.sql.api.SessionImpl#close relies on the fact that the returned CompletableFuture will be complited only after all resources have been closed. However, org.apache.ignite.internal.sql.api.SessionImpl#closeAsync returns a always ready facke CompletableFuture. The closeInternal() method needs to be slightly reworked to return a real CompletableFuture and start using the return value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21089) [YCSB] "IgniteException: readerIndex: 0, writerIndex: 257" on SQL SELECT
[
https://issues.apache.org/jira/browse/IGNITE-21089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803016#comment-17803016
]
Yury Gerzhedovich commented on IGNITE-21089:
[~Artukhov] could you please switch on sendServerExceptionStackTraceToClient
property for all tests?
It give us more information.
> [YCSB] "IgniteException: readerIndex: 0, writerIndex: 257" on SQL SELECT
>
>
> Key: IGNITE-21089
> URL: https://issues.apache.org/jira/browse/IGNITE-21089
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Ivan Artiukhov
>Priority: Major
> Labels: ignite-3
> Attachments: 2023-12-15-04-58-54_run.txt, logs-818.zip
>
>
> AI3 rev. {{ba6cd4dfff0e4bc2eacb437a1331454e030bff84}}
> Benchmark:
> [https://github.com/gridgain/YCSB/blob/ycsb-2023.9/ignite3/src/main/java/site/ycsb/db/ignite3/IgniteSqlClient.java]
>
> The benchmark uses Ignite 3 Java SQL API to perform SQL queries.
> h1. Setup
> 1 server node, 1 client node (1 thread)
> h1. Steps
> The benchmark was started 2 times:
> # in {{load}} mode to preload 165k unique entries via {{INSERT}} (15k in
> warmup phase + 150k in payload phase)
> # in {{run}} mode to {{SELECT}} each entry one by one
> h1. Expected result
> # The {{load}} mode finishes successfully without errors
> # The {{run}} mode finishes successfully without errors
> h1. Actual result
> # The {{load}} mode finishes successfully without errors
> # In the {{run}} mode the very first 128 entries were read with the
> following error. All other entries were read successfully.
> {noformat}
> org.apache.ignite.lang.IgniteException: readerIndex: 0, writerIndex: 257
> (expected: 0 <= readerIndex <= writerIndex <= capacity(256))
> at
> java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
> ~[?:?]
> at
> org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:754)
> ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:688)
> ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:525)
> ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:623)
> ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:476)
> ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.sql.AbstractSession.execute(AbstractSession.java:63)
> ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
> at site.ycsb.db.ignite3.IgniteSqlClient.read(IgniteSqlClient.java:51)
> [ignite3-binding-2023.9.jar:?]
> at site.ycsb.DBWrapper.read(DBWrapper.java:145) [core-2023.9.jar:?]
> at
> site.ycsb.workloads.CoreWorkload.doTransactionRead(CoreWorkload.java:746)
> [core-2023.9.jar:?]
> at
> site.ycsb.workloads.CoreWorkload.doTransaction(CoreWorkload.java:666)
> [core-2023.9.jar:?]
> at site.ycsb.ClientThread.run(ClientThread.java:145) [core-2023.9.jar:?]
> at java.lang.Thread.run(Thread.java:829) [?:?]
> Caused by: java.util.concurrent.CompletionException:
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:b0e3aa62-ba41-47bd-8238-f39537f78e28 readerIndex: 0, writerIndex: 257
> (expected: 0 <= readerIndex <= writerIndex <= capacity(256))
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:632)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> ~[?:?]
> at
> org.apache.ignite.internal.client.TcpClientChannel.processNextMessage(TcpClientChannel.java:417)
> ~[ignite-client-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.client.TcpClientChannel.lambda$onMessage$3(TcpClientChannel.java:241)
> ~[ignite-client-3.0.0-SNAPSHOT.jar:?]
> at
> java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1426)
> ~[?:?]
> at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
> ~[?:?]
> at
> java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
> ~[?:?]
> at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656) ~[?:?]
> at
[jira] [Updated] (IGNITE-21080) Improve of calculation cache sizes for SQL engine
[ https://issues.apache.org/jira/browse/IGNITE-21080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-21080: --- Description: As of now we use hardcoded constants for our internal caches, it looks wrong. These constants for first glance shouldn't be configured by user, but we could use calculated estimated size. Let't make the improvement: ||Constant||Proposed calculation|| |SqlQueryProcessor#PARSED_RESULT_CACHE_SIZE |SqlQueryProcessor#PLAN_CACHE_SIZE *3| |ExecutionServiceImpl#CACHE_SIZE|SqlQueryProcessor#PLAN_CACHE_SIZE * 3| |SqlQueryProcessor#TABLE_CACHE_SIZE|number of tables * 2 (need to be discussed) | |SqlQueryProcessor#SCHEMA_CACHE_SIZE|as of now used for two caches, need to use TABLE_CACHE_SIZE for table cache, and keep as is for catalog versions.| | | | We could introduce recreate caches for significant change amount of tables in a cluster. was: As of now we use hardcoded constants for our internal caches, it looks wrong. These constants for first glance shouldn't be configured by user, but we could use calculated estimated size. Let't make the improvement: ||Constant||Proposed calculation|| |SqlQueryProcessor#PARSED_RESULT_CACHE_SIZE |SqlQueryProcessor#PLAN_CACHE_SIZE *3| |ExecutionServiceImpl#CACHE_SIZE|SqlQueryProcessor#PLAN_CACHE_SIZE * 3| |SqlQueryProcessor#TABLE_CACHE_SIZE|number of tables * 2| |SqlQueryProcessor#SCHEMA_CACHE_SIZE|as of now used for two caches, need to use TABLE_CACHE_SIZE for table cache, and keep as is for catalog versions.| | | | We could introduce recreate caches for significant change amount of tables in a cluster. > Improve of calculation cache sizes for SQL engine > - > > Key: IGNITE-21080 > URL: https://issues.apache.org/jira/browse/IGNITE-21080 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > As of now we use hardcoded constants for our internal caches, it looks wrong. > These constants for first glance shouldn't be configured by user, but we > could use calculated estimated size. > Let't make the improvement: > ||Constant||Proposed calculation|| > |SqlQueryProcessor#PARSED_RESULT_CACHE_SIZE > |SqlQueryProcessor#PLAN_CACHE_SIZE *3| > |ExecutionServiceImpl#CACHE_SIZE|SqlQueryProcessor#PLAN_CACHE_SIZE * 3| > |SqlQueryProcessor#TABLE_CACHE_SIZE|number of tables * 2 (need to be > discussed) | > |SqlQueryProcessor#SCHEMA_CACHE_SIZE|as of now used for two caches, need to > use TABLE_CACHE_SIZE for table cache, and keep as is for catalog versions.| > | | | > We could introduce recreate caches for significant change amount of tables in > a cluster. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17703) Extaract hardcoded constants to configuration in sql-engine module
[ https://issues.apache.org/jira/browse/IGNITE-17703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-17703: --- Description: We have many hardcoded constants in sql-engine module. So it can't be configure by user. Let's move the following to configuration: ||Constant||Configuration path|| |PrepareServiceImpl#DEFAULT_PLANNER_TIMEOUT|sql.planner.maxPlanningTime| |PrepareServiceImpl#THREAD_COUNT|sql.planner.threadCount| |SqlQueryProcessor#PLAN_CACHE_SIZE|sql.planner.estimatedNumberOfQueries| |QueryTaskExecutorImpl.stripedThreadPoolExecutor|sql.execution.concurrencyLevel| | | | was: We have many hardcoded constants in sql-engine module. So it can't be configure by user. Let's move the following to configuration: ||Constant||Configuration path|| |PrepareServiceImpl#DEFAULT_PLANNER_TIMEOUT|sql.planner.maxPlanningTime| |PrepareServiceImpl#THREAD_COUNT|sql.planner.threadCount| |SqlQueryProcessor#PLAN_CACHE_SIZE|sql.planner.estimatedNumberOfQueries| |QueryTaskExecutorImpl.stripedThreadPoolExecutor|sql.execution.concurrencyLevel| | | | | | | | | | | | | > Extaract hardcoded constants to configuration in sql-engine module > -- > > Key: IGNITE-17703 > URL: https://issues.apache.org/jira/browse/IGNITE-17703 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3, tech-debt > > We have many hardcoded constants in sql-engine module. So it can't be > configure by user. > Let's move the following to configuration: > ||Constant||Configuration path|| > |PrepareServiceImpl#DEFAULT_PLANNER_TIMEOUT|sql.planner.maxPlanningTime| > |PrepareServiceImpl#THREAD_COUNT|sql.planner.threadCount| > |SqlQueryProcessor#PLAN_CACHE_SIZE|sql.planner.estimatedNumberOfQueries| > |QueryTaskExecutorImpl.stripedThreadPoolExecutor|sql.execution.concurrencyLevel| > | | | -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21080) Improve of calculation cache sizes for SQL engine
[ https://issues.apache.org/jira/browse/IGNITE-21080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-21080: --- Description: As of now we use hardcoded constants for our internal caches, it looks wrong. These constants for first glance shouldn't be configured by user, but we could use calculated estimated size. Let't make the improvement: ||Constant||Proposed calculation|| |SqlQueryProcessor#PARSED_RESULT_CACHE_SIZE |SqlQueryProcessor#PLAN_CACHE_SIZE *3| |ExecutionServiceImpl#CACHE_SIZE|SqlQueryProcessor#PLAN_CACHE_SIZE * 3| |SqlQueryProcessor#TABLE_CACHE_SIZE|number of tables * 2| |SqlQueryProcessor#SCHEMA_CACHE_SIZE|as of now used for two caches, need to use TABLE_CACHE_SIZE for table cache, and keep as is for catalog versions.| | | | We could introduce recreate caches for significant change amount of tables in a cluster. was: As of now we use hardcoded constants for our internal caches, it looks wrong. These constants for first glance shouldn't be configured by user, but we could use calculated estimated size. Let't make the improvement: ||Constant||Proposed calculation|| |SqlQueryProcessor#PARSED_RESULT_CACHE_SIZE |SqlQueryProcessor#PLAN_CACHE_SIZE *3| |ExecutionServiceImpl#CACHE_SIZE|SqlQueryProcessor#PLAN_CACHE_SIZE * 3| |SqlQueryProcessor#TABLE_CACHE_SIZE|number of tables * 2| |SqlQueryProcessor#SCHEMA_CACHE_SIZE|as of now used for two caches, need to use TABLE_CACHE_SIZE for table cache, and keep as is for catalog versions.| | | | We could introduce recreate caches for significant change amount of tables in a cluster. - - > Improve of calculation cache sizes for SQL engine > - > > Key: IGNITE-21080 > URL: https://issues.apache.org/jira/browse/IGNITE-21080 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > As of now we use hardcoded constants for our internal caches, it looks wrong. > These constants for first glance shouldn't be configured by user, but we > could use calculated estimated size. > Let't make the improvement: > ||Constant||Proposed calculation|| > |SqlQueryProcessor#PARSED_RESULT_CACHE_SIZE > |SqlQueryProcessor#PLAN_CACHE_SIZE *3| > |ExecutionServiceImpl#CACHE_SIZE|SqlQueryProcessor#PLAN_CACHE_SIZE * 3| > |SqlQueryProcessor#TABLE_CACHE_SIZE|number of tables * 2| > |SqlQueryProcessor#SCHEMA_CACHE_SIZE|as of now used for two caches, need to > use TABLE_CACHE_SIZE for table cache, and keep as is for catalog versions.| > | | | > We could introduce recreate caches for significant change amount of tables in > a cluster. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21080) Improve of calculation cache sizes for SQL engine
[ https://issues.apache.org/jira/browse/IGNITE-21080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-21080: --- Issue Type: Improvement (was: Bug) > Improve of calculation cache sizes for SQL engine > - > > Key: IGNITE-21080 > URL: https://issues.apache.org/jira/browse/IGNITE-21080 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > As of now we use hardcoded constants for our internal caches, it looks wrong. > These constants for first glance shouldn't be configured by user, but we > could use calculated estimated size. > Let't make the improvement: > ||Constant||Proposed calculation|| > |SqlQueryProcessor#PARSED_RESULT_CACHE_SIZE > |SqlQueryProcessor#PLAN_CACHE_SIZE *3| > |ExecutionServiceImpl#CACHE_SIZE|SqlQueryProcessor#PLAN_CACHE_SIZE * 3| > |SqlQueryProcessor#TABLE_CACHE_SIZE|number of tables * 2| > |SqlQueryProcessor#SCHEMA_CACHE_SIZE|as of now used for two caches, need to > use TABLE_CACHE_SIZE for table cache, and keep as is for catalog versions.| > | | | > We could introduce recreate caches for significant change amount of tables in > a cluster. > - > - > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21080) Improve of calculation cache sizes for SQL engine
Yury Gerzhedovich created IGNITE-21080: -- Summary: Improve of calculation cache sizes for SQL engine Key: IGNITE-21080 URL: https://issues.apache.org/jira/browse/IGNITE-21080 Project: Ignite Issue Type: Bug Components: sql Reporter: Yury Gerzhedovich As of now we use hardcoded constants for our internal caches, it looks wrong. These constants for first glance shouldn't be configured by user, but we could use calculated estimated size. Let't make the improvement: ||Constant||Proposed calculation|| |SqlQueryProcessor#PARSED_RESULT_CACHE_SIZE |SqlQueryProcessor#PLAN_CACHE_SIZE *3| |ExecutionServiceImpl#CACHE_SIZE|SqlQueryProcessor#PLAN_CACHE_SIZE * 3| |SqlQueryProcessor#TABLE_CACHE_SIZE|number of tables * 2| |SqlQueryProcessor#SCHEMA_CACHE_SIZE|as of now used for two caches, need to use TABLE_CACHE_SIZE for table cache, and keep as is for catalog versions.| | | | We could introduce recreate caches for significant change amount of tables in a cluster. - - -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17703) Extaract hardcoded constants to configuration in sql-engine module
[ https://issues.apache.org/jira/browse/IGNITE-17703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-17703: --- Description: We have many hardcoded constants in sql-engine module. So it can't be configure by user. Let's move the following to configuration: ||Constant||Configuration path|| |PrepareServiceImpl#DEFAULT_PLANNER_TIMEOUT|sql.planner.maxPlanningTime| |PrepareServiceImpl#THREAD_COUNT|sql.planner.threadCount| |SqlQueryProcessor#PLAN_CACHE_SIZE|sql.planner.estimatedNumberOfQueries| |QueryTaskExecutorImpl.stripedThreadPoolExecutor|sql.execution.concurrencyLevel| | | | | | | | | | | | | was: We have many hardcoded constants in sql-engine module. So it can't be configure by user. Let's find and identify all of them and move it to configuration. > Extaract hardcoded constants to configuration in sql-engine module > -- > > Key: IGNITE-17703 > URL: https://issues.apache.org/jira/browse/IGNITE-17703 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3, tech-debt > > We have many hardcoded constants in sql-engine module. So it can't be > configure by user. > Let's move the following to configuration: > ||Constant||Configuration path|| > |PrepareServiceImpl#DEFAULT_PLANNER_TIMEOUT|sql.planner.maxPlanningTime| > |PrepareServiceImpl#THREAD_COUNT|sql.planner.threadCount| > |SqlQueryProcessor#PLAN_CACHE_SIZE|sql.planner.estimatedNumberOfQueries| > |QueryTaskExecutorImpl.stripedThreadPoolExecutor|sql.execution.concurrencyLevel| > | | | > | | | > | | | > | | | -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20997) Sql. Improve the error message when attempting to divide by zero.
[
https://issues.apache.org/jira/browse/IGNITE-20997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich reassigned IGNITE-20997:
--
Assignee: Yury Gerzhedovich
> Sql. Improve the error message when attempting to divide by zero.
> -
>
> Key: IGNITE-20997
> URL: https://issues.apache.org/jira/browse/IGNITE-20997
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Yury Gerzhedovich
>Priority: Minor
> Labels: ignite-3
>
> It seems worth improving the error message when attempting to divide by zero,
> because the current message seems a bit confusing.
> {code:SQL}
> SELECT 1/0
> {code}
> Apache Ignite 3: "/ by zero"
> PostgreSQL: "ERROR: division by zero"
> MS SQL: "Divide by zero error encountered"
> Oracle: "ORA-01476: divisor is equal to zero"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21036) Add possibility to obtain parameters of already existing zone.
[ https://issues.apache.org/jira/browse/IGNITE-21036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-21036: --- Summary: Add possibility to obtain parameters of already existing zone. (was: Sql. Add possibility to obtain parameters of already existing zone.) > Add possibility to obtain parameters of already existing zone. > -- > > Key: IGNITE-21036 > URL: https://issues.apache.org/jira/browse/IGNITE-21036 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > For now it`s possible to create distributed zone with different configurable > parameters, like: > "CREATE ZONE name_of_the_zone WITH partitions=7, DATA_NODES_AUTO_ADJUST=100" > but there is no way to obtain this zone params using public api (views, > jmx?). Seems we need such a functionality. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-15571) JOIN with USING fails with : USING clause is not unique on one side of join.
[
https://issues.apache.org/jira/browse/IGNITE-15571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795084#comment-17795084
]
Yury Gerzhedovich commented on IGNITE-15571:
[~zstan] LGTM
> JOIN with USING fails with : USING clause is not unique on one side of join.
>
>
> Key: IGNITE-15571
> URL: https://issues.apache.org/jira/browse/IGNITE-15571
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: calcite, calcite2-required, ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {noformat}
> statement ok
> CREATE TABLE t1 (a INTEGER, b INTEGER, c INTEGER)
> statement ok
> INSERT INTO t1 VALUES (1,2,3)
> statement ok
> CREATE TABLE t2 (a INTEGER, b INTEGER, c INTEGER)
> statement ok
> INSERT INTO t2 VALUES (1,2,3), (2,2,4), (1,3,4)
> query III
> SELECT * FROM t1 JOIN t2 USING(a) JOIN t2 t2b USING (a) ORDER BY 1, 2, 3, 4,
> 5, 6, 7
>
> 1 2 3 2 3 2 3
> 1 2 3 2 3 3 4
> 1 2 3 3 4 2 3
> 1 2 3 3 4 3 4
> {noformat}
> fails with
> {noformat}
> org.apache.calcite.runtime.CalciteContextException: At line 1, column 54:
> Column name 'A' in USING clause is not unique on one side of join
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:506)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:917)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:902)
> {noformat}
> {noformat}
> /join/inner/test_using_join.test[_ignore]
> {noformat}
> checked on mysql - all ok.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-16204) Calcite integration. Muted JDBC multistatement test
[ https://issues.apache.org/jira/browse/IGNITE-16204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich resolved IGNITE-16204. Resolution: Not A Problem > Calcite integration. Muted JDBC multistatement test > --- > > Key: IGNITE-16204 > URL: https://issues.apache.org/jira/browse/IGNITE-16204 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Vladimir Ermakov >Priority: Major > Labels: ignite-3 > > Let's remove muted test.. org.apache.ignite.jdbc.ItJdbcMultiStatementSelfTest -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-20048) Wrong null type for null values in DB tools
[
https://issues.apache.org/jira/browse/IGNITE-20048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich resolved IGNITE-20048.
Resolution: Cannot Reproduce
Seems the issue already fixed
> Wrong null type for null values in DB tools
> ---
>
> Key: IGNITE-20048
> URL: https://issues.apache.org/jira/browse/IGNITE-20048
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0
>Reporter: Alexander Belyak
>Priority: Major
> Labels: ignite-3
>
> In tools like DB Visualizer, IDEA, DBeaver user will get:
> * 0 instead of null in integer fields
> * false instead of null in varchar fields
> Reproducer:
> {noformat}
> DROP TABLE IF EXISTS test;
> CREATE TABLE test (id int PRIMARY KEY, vali int, vals varchar);
> INSERT INTO test(id, vali, vals) values(1,1,'1'),(2,NULL,'2'),(3,3,null);
> SELECT * FROM test{noformat}
> Expected result:
> {noformat}
> ID VALI VALS3
> 3 3(null)
> 2 (null) 2
> 1 11{noformat}
> Actual results:
> {noformat}
> ID VALI VALS3
> 3 3false
> 2 02
> 1 11{noformat}
> Commit id: f34beaed
> But actually database store null values, for example, queries like:
> {noformat}
> SELECT * FROM test WHERE vali IS null{noformat}
> will return:
> {noformat}
> ID VALI VALS3
> 2 0 2{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20906) Attempt to change column type from INT to BIGINT fails
[ https://issues.apache.org/jira/browse/IGNITE-20906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-20906: --- Epic Link: IGNITE-20907 > Attempt to change column type from INT to BIGINT fails > -- > > Key: IGNITE-20906 > URL: https://issues.apache.org/jira/browse/IGNITE-20906 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > CREATE TABLE t (id INT PRIMARY KEY, val INT NOT NULL); > ALTER TABLE t ALTER COLUMN val SET DATA TYPE BIGINT; > Second query fails with the following message 'Changing the precision for > column of type 'INT32' is not allowed', alghough precision is not mentioned > in any of the queries. > Same thing happens when trying to change SMALLINT -> INT. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20937) Extract JDBC tests from runner module to ignite-jdbc
[ https://issues.apache.org/jira/browse/IGNITE-20937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich reassigned IGNITE-20937: -- Assignee: Yury Gerzhedovich > Extract JDBC tests from runner module to ignite-jdbc > > > Key: IGNITE-20937 > URL: https://issues.apache.org/jira/browse/IGNITE-20937 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > Runner module incorporate big amount of tests related to another modules. > That's lead to long running time for the suite on TC. > Currently, intergation tests for JDBC functionallity located in ignite-runner > module. So, need to extract it to JDBC module via runner test-fixtures > support to decrease execution time of test for runner module. > As reference for such activities could be used IGNITE-20670 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21016) ItMixedQueriesTest.testIgniteSchemaAwaresAlterTableCommand is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-21016:
---
Summary: ItMixedQueriesTest.testIgniteSchemaAwaresAlterTableCommand is
flaky (was: tMixedQueriesTest.testIgniteSchemaAwaresAlterTableCommand is flaky)
> ItMixedQueriesTest.testIgniteSchemaAwaresAlterTableCommand is flaky
> ---
>
> Key: IGNITE-21016
> URL: https://issues.apache.org/jira/browse/IGNITE-21016
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
>
> The test
> org.apache.ignite.internal.sql.engine.ItMixedQueriesTest#testIgniteSchemaAwaresAlterTableCommand
> is flacky.
> The issue periodically appears on TC, also reproducable on local environment.
> {code:java}
> org.opentest4j.AssertionFailedError: Column metadata doesn't match ==>
> expected: <3> but was: <2>
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at
> app//org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
> at
> app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
> at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:560)
> at
> app//org.apache.ignite.internal.sql.engine.util.QueryCheckerImpl.check(QueryCheckerImpl.java:322)
> at
> app//org.apache.ignite.internal.sql.engine.util.QueryCheckerFactoryImpl$1.check(QueryCheckerFactoryImpl.java:90)
> at
> app//org.apache.ignite.internal.sql.engine.ItMixedQueriesTest.testIgniteSchemaAwaresAlterTableCommand(ItMixedQueriesTest.java:221)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21016) ItMixedQueriesTest.testIgniteSchemaAwaresAlterTableCommand is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-21016:
---
Labels: ignite-3 (was: )
> ItMixedQueriesTest.testIgniteSchemaAwaresAlterTableCommand is flaky
> ---
>
> Key: IGNITE-21016
> URL: https://issues.apache.org/jira/browse/IGNITE-21016
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> The test
> org.apache.ignite.internal.sql.engine.ItMixedQueriesTest#testIgniteSchemaAwaresAlterTableCommand
> is flacky.
> The issue periodically appears on TC, also reproducable on local environment.
> {code:java}
> org.opentest4j.AssertionFailedError: Column metadata doesn't match ==>
> expected: <3> but was: <2>
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at
> app//org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
> at
> app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
> at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:560)
> at
> app//org.apache.ignite.internal.sql.engine.util.QueryCheckerImpl.check(QueryCheckerImpl.java:322)
> at
> app//org.apache.ignite.internal.sql.engine.util.QueryCheckerFactoryImpl$1.check(QueryCheckerFactoryImpl.java:90)
> at
> app//org.apache.ignite.internal.sql.engine.ItMixedQueriesTest.testIgniteSchemaAwaresAlterTableCommand(ItMixedQueriesTest.java:221)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21016) tMixedQueriesTest.testIgniteSchemaAwaresAlterTableCommand is flaky
Yury Gerzhedovich created IGNITE-21016:
--
Summary: tMixedQueriesTest.testIgniteSchemaAwaresAlterTableCommand
is flaky
Key: IGNITE-21016
URL: https://issues.apache.org/jira/browse/IGNITE-21016
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Yury Gerzhedovich
The test
org.apache.ignite.internal.sql.engine.ItMixedQueriesTest#testIgniteSchemaAwaresAlterTableCommand
is flacky.
The issue periodically appears on TC, also reproducable on local environment.
{code:java}
org.opentest4j.AssertionFailedError: Column metadata doesn't match ==>
expected: <3> but was: <2>
at
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at app//org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:560)
at
app//org.apache.ignite.internal.sql.engine.util.QueryCheckerImpl.check(QueryCheckerImpl.java:322)
at
app//org.apache.ignite.internal.sql.engine.util.QueryCheckerFactoryImpl$1.check(QueryCheckerFactoryImpl.java:90)
at
app//org.apache.ignite.internal.sql.engine.ItMixedQueriesTest.testIgniteSchemaAwaresAlterTableCommand(ItMixedQueriesTest.java:221)
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20972) Move handlers of zone-related commands from CatalogManager
[ https://issues.apache.org/jira/browse/IGNITE-20972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-20972: --- Description: As described in IGNITE-20284, we need to restructure code to improve code locality and avoid conflict when introducing new commands in future. Under this ticket let's address zone-related commands. was: As described in IGNITE-20284, we need to restructure code to improve code locality and avoid conflict when introducing new commands in future. Under this ticket let's address zone-related commands. > Move handlers of zone-related commands from CatalogManager > -- > > Key: IGNITE-20972 > URL: https://issues.apache.org/jira/browse/IGNITE-20972 > Project: Ignite > Issue Type: Improvement >Reporter: Konstantin Orlov >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > As described in IGNITE-20284, we need to restructure code to improve code > locality and avoid conflict when introducing new commands in future. > Under this ticket let's address zone-related commands. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20098) Move exception classes related to distribution zones to an appropriate package/module
[ https://issues.apache.org/jira/browse/IGNITE-20098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-20098: --- Description: The following exceptions classes were moved to the `core` module due to CatalogService feature: - DistributionZoneNotFoundException - DistributionZoneBindTableException - DistributionZoneAlreadyExistsException It seems to me, that this is not the correct way to handle dependencies between `catalog` and `distribution zone` modules. All exceptions should be moved to the one place. IMHO, it should be the `distribution zone` module. was: The following exceptions classes were moved to the `core` module due to CatalogService feature: - DistributionZoneNotFoundException - DistributionZoneBindTableException - DistributionZoneAlreadyExistsException It seems to me, that this is not the correct way to handle dependencies between `catalog` and `distribution zone` modules. All exceptions should be moved to the one place. IMHO, it should be the `distribution zone` module. > Move exception classes related to distribution zones to an appropriate > package/module > - > > Key: IGNITE-20098 > URL: https://issues.apache.org/jira/browse/IGNITE-20098 > Project: Ignite > Issue Type: Bug >Reporter: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > > The following exceptions classes were moved to the `core` module due to > CatalogService feature: > - DistributionZoneNotFoundException > - DistributionZoneBindTableException > - DistributionZoneAlreadyExistsException > It seems to me, that this is not the correct way to handle dependencies > between `catalog` and `distribution zone` modules. All exceptions should be > moved to the one place. IMHO, it should be the `distribution zone` module. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20876) Data cannot be queried from the ignite
[ https://issues.apache.org/jira/browse/IGNITE-20876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790610#comment-17790610 ] Yury Gerzhedovich commented on IGNITE-20876: [~bdq] sequence of actions which lead to the issue. Ideality is should be runnable code to reproduce the issue. Otherwise such bug can't be investigated and fixed > Data cannot be queried from the ignite > -- > > Key: IGNITE-20876 > URL: https://issues.apache.org/jira/browse/IGNITE-20876 > Project: Ignite > Issue Type: Bug >Reporter: biandeqiang >Priority: Major > > The following exception is thrown when data is queried from the ignite: > [2023-11-17 10:07:08.248+0800][WARN ][0][query-#14823][][IgniteLoggerImp][88] > Failed to process message: [srcNodeId=4845504d-cd1d-4d3a-8726-399633ca6b91, > msg=GridQueryNextPageResponse [qryReqId=754, segmentId=7, qry=0, page=0, > allRows=548, cols=6, retry=null, retryCause=null, last=true, > removeMapping=false, valsSize=3288, rowsSize=0]] > java.lang.ArrayIndexOutOfBoundsException: 7 > at > org.apache.ignite.internal.processors.query.h2.twostep.SortedReducer.addPage0(SortedReducer.java:217) > at > org.apache.ignite.internal.processors.query.h2.twostep.AbstractReducer.addPage(AbstractReducer.java:217) > at > org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.onNextPage(GridReduceQueryExecutor.java:303) > at > org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.onMessage(IgniteH2Indexing.java:2214) > at > org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.lambda$start$23(IgniteH2Indexing.java:2153) > at > org.apache.ignite.internal.managers.communication.GridIoManager$ArrayListener.onMessage(GridIoManager.java:3482) > 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 > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:750) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20876) Data cannot be queried from the ignite
[ https://issues.apache.org/jira/browse/IGNITE-20876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790516#comment-17790516 ] Yury Gerzhedovich commented on IGNITE-20876: [~bdq] do you have an reproducer? > Data cannot be queried from the ignite > -- > > Key: IGNITE-20876 > URL: https://issues.apache.org/jira/browse/IGNITE-20876 > Project: Ignite > Issue Type: Bug >Reporter: biandeqiang >Priority: Major > > The following exception is thrown when data is queried from the ignite: > [2023-11-17 10:07:08.248+0800][WARN ][0][query-#14823][][IgniteLoggerImp][88] > Failed to process message: [srcNodeId=4845504d-cd1d-4d3a-8726-399633ca6b91, > msg=GridQueryNextPageResponse [qryReqId=754, segmentId=7, qry=0, page=0, > allRows=548, cols=6, retry=null, retryCause=null, last=true, > removeMapping=false, valsSize=3288, rowsSize=0]] > java.lang.ArrayIndexOutOfBoundsException: 7 > at > org.apache.ignite.internal.processors.query.h2.twostep.SortedReducer.addPage0(SortedReducer.java:217) > at > org.apache.ignite.internal.processors.query.h2.twostep.AbstractReducer.addPage(AbstractReducer.java:217) > at > org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.onNextPage(GridReduceQueryExecutor.java:303) > at > org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.onMessage(IgniteH2Indexing.java:2214) > at > org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.lambda$start$23(IgniteH2Indexing.java:2153) > at > org.apache.ignite.internal.managers.communication.GridIoManager$ArrayListener.onMessage(GridIoManager.java:3482) > 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 > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:750) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-20762) Unable to create table in a specific zone
[
https://issues.apache.org/jira/browse/IGNITE-20762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich resolved IGNITE-20762.
Resolution: Not A Problem
It looks not a problem due to we uppercase (to have case-insensitive) all
identifiers in SQ.
so after create zone fz you have name FZ, but when you try to use the zone you
use quoted identifier, which not uppercases. So you should use or uppercased
quote identifier or don't use quotes.
> Unable to create table in a specific zone
> -
>
> Key: IGNITE-20762
> URL: https://issues.apache.org/jira/browse/IGNITE-20762
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0
>Reporter: Alexander Belyak
>Priority: Major
> Labels: ignite-3
>
> Got exception
> [Code: 0, SQL State: 5] Failed to validate query. Distribution zone with
> name 'fz' not found
> on creation a new table in any specific zone:
> {noformat}
> create zone fz engine aipersist;
> >> success
> create table testt3 (id integer not null, val varchar not null, id2 integer
> not null, primary key(id,id2) ) with primary_zone = 'fz';
> >> [Code: 0, SQL State: 5] Failed to validate query. Distribution zone
> >> with name 'fz' not found
> create zone fz engine aipersist;
> >> [Code: 0, SQL State: 5] Distribution zone already exists [zoneName=FZ]
> drop zone fz;
> >> success{noformat}
> Code from the example:
> [https://github.com/apache/ignite-3/blob/main/examples/src/main/java/org/apache/ignite/example/storage/StorageEngineExample.java]
> no matter if the first statement will use any region:
> {noformat}
> create zone fz2 engine aipersist with dataregion = 'asd';
> >> success
> create table testt3 (id integer not null, val varchar not null, id2 integer
> not null, primary key(id,id2) ) with primary_zone = 'fz2';
> >> [Code: 0, SQL State: 5] Failed to validate query. Distribution zone
> >> with name 'fz2' not found{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-20622) OOMe during TPC-C scale10
[ https://issues.apache.org/jira/browse/IGNITE-20622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich resolved IGNITE-20622. Resolution: Cannot Reproduce > OOMe during TPC-C scale10 > - > > Key: IGNITE-20622 > URL: https://issues.apache.org/jira/browse/IGNITE-20622 > Project: Ignite > Issue Type: Bug > Components: networking >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > Got OOMe during loading TPC-C database with scale 10 (benchbase). Just > starting benchbase with TPC-C benchmark with scale factor is enough to get > stable OOMe exception in 10 min. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20938) Extract SQL tests from runner module to ignite-sql-engine
[ https://issues.apache.org/jira/browse/IGNITE-20938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-20938: --- Description: Runner module incorporate big amount of tests related to another modules. That's lead to long running time for the suite on TC. Currently, intergation tests for SQL functionallity located in ignite-runner module. So, need to extract it to ignite-sql-engine module via runner test-fixtures support to decrease execution time of test for runner module. As reference for such activities could be used IGNITE-20670 was: Runner module incorporate big amount of tests related to another modules. That's lead to long running time for the suite on TC. Currently, intergation tests for SQL functionallity located in ignite-runner module. So, need to extract it to ignite-sql-engine module via runner test-fixtures support to decrease execution time of test for runner module. > Extract SQL tests from runner module to ignite-sql-engine > - > > Key: IGNITE-20938 > URL: https://issues.apache.org/jira/browse/IGNITE-20938 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > Runner module incorporate big amount of tests related to another modules. > That's lead to long running time for the suite on TC. > Currently, intergation tests for SQL functionallity located in ignite-runner > module. So, need to extract it to ignite-sql-engine module via runner > test-fixtures support to decrease execution time of test for runner module. > As reference for such activities could be used IGNITE-20670 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20937) Extract JDBC tests from runner module to ignite-jdbc
[ https://issues.apache.org/jira/browse/IGNITE-20937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-20937: --- Description: Runner module incorporate big amount of tests related to another modules. That's lead to long running time for the suite on TC. Currently, intergation tests for JDBC functionallity located in ignite-runner module. So, need to extract it to JDBC module via runner test-fixtures support to decrease execution time of test for runner module. As reference for such activities could be used IGNITE-20670 was: Runner module incorporate big amount of tests related to another modules. That's lead to long running time for the suite on TC. Currently, intergation tests for JDBC functionallity located in ignite-runner module. So, need to extract it to JDBC module via runner test-fixtures support to decrease execution time of test for runner module > Extract JDBC tests from runner module to ignite-jdbc > > > Key: IGNITE-20937 > URL: https://issues.apache.org/jira/browse/IGNITE-20937 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > Runner module incorporate big amount of tests related to another modules. > That's lead to long running time for the suite on TC. > Currently, intergation tests for JDBC functionallity located in ignite-runner > module. So, need to extract it to JDBC module via runner test-fixtures > support to decrease execution time of test for runner module. > As reference for such activities could be used IGNITE-20670 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20938) Extract SQL tests from runner module to ignite-sql-engine
Yury Gerzhedovich created IGNITE-20938: -- Summary: Extract SQL tests from runner module to ignite-sql-engine Key: IGNITE-20938 URL: https://issues.apache.org/jira/browse/IGNITE-20938 Project: Ignite Issue Type: Improvement Components: sql Reporter: Yury Gerzhedovich Runner module incorporate big amount of tests related to another modules. That's lead to long running time for the suite on TC. Currently, intergation tests for SQL functionallity located in ignite-runner module. So, need to extract it to ignite-sql-engine module via runner test-fixtures support to decrease execution time of test for runner module. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20937) Extract JDBC tests from runner module to ignite-jdbc
Yury Gerzhedovich created IGNITE-20937: -- Summary: Extract JDBC tests from runner module to ignite-jdbc Key: IGNITE-20937 URL: https://issues.apache.org/jira/browse/IGNITE-20937 Project: Ignite Issue Type: Improvement Components: sql Reporter: Yury Gerzhedovich Runner module incorporate big amount of tests related to another modules. That's lead to long running time for the suite on TC. Currently, intergation tests for JDBC functionallity located in ignite-runner module. So, need to extract it to JDBC module via runner test-fixtures support to decrease execution time of test for runner module -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20885) Sql. Bump calcite version to 1.36
[ https://issues.apache.org/jira/browse/IGNITE-20885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-20885: --- Summary: Sql. Bump calcite version to 1.36 (was: SQL. Bump calcite version to 1.36) > Sql. Bump calcite version to 1.36 > - > > Key: IGNITE-20885 > URL: https://issues.apache.org/jira/browse/IGNITE-20885 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Evgeny Stanilovsky >Priority: Major > > New version is resolved, also [3] consists in this version and we can > simplify corresponding (SqlKind.DEFAULT keyword) code in > IgniteSqlToRelConvertor implemented here [2] > [1] https://calcite.apache.org/docs/history.html#v1-36-0 > [2] https://issues.apache.org/jira/browse/IGNITE-19096 > [3] https://issues.apache.org/jira/browse/CALCITE-5950 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20813) Sql. Introduce InternalSqlRow as resulting row of QueryProcessor
[
https://issues.apache.org/jira/browse/IGNITE-20813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich reassigned IGNITE-20813:
--
Assignee: Yury Gerzhedovich
> Sql. Introduce InternalSqlRow as resulting row of QueryProcessor
>
>
> Key: IGNITE-20813
> URL: https://issues.apache.org/jira/browse/IGNITE-20813
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> As for now, the method signature of
> {{QueryProcessor#querySingleAsync}} looks like this:
> {code:java}
> CompletableFuture>> querySingleAsync(
> SqlProperties properties,
> IgniteTransactions transactions,
> @Nullable InternalTransaction transaction,
> String qry,
> Object... params
> );
> {code}
>
> The problem is that client code may not need de-serialised row right here
> right now (for instance, thin client handler will send those rows down the
> channel anyway), yet current signature force us to do deserialisation from a
> storage format.
> Let's change the signature to return something that extends InternalTuple,
> but also provides a way to get column value by having only index of column of
> interest (e.g. {{@Nullable Object get(int idx)}}).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20501) Calcite engine. Memory leak in MailboxRegistryImpl#remotes on JOINs
[
https://issues.apache.org/jira/browse/IGNITE-20501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-20501:
---
Labels: calcite calcite3-required ignite ise (was: calcite ise)
> Calcite engine. Memory leak in MailboxRegistryImpl#remotes on JOINs
> ---
>
> Key: IGNITE-20501
> URL: https://issues.apache.org/jira/browse/IGNITE-20501
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, calcite3-required, ignite, ise
> Fix For: 2.16
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When JOIN relational operator is executed, downstream of JOIN can be closed
> if only one side of JOIN is already drained (see last lines of
> {{MergeJoinNode.InnerJoin#join}}, for example). In this case query can be
> prematurely closed, and after this, message for another side of join can
> arrive and register new {{Inbox}} (see {{ExchangeServiceImpl#onMessage(UUID,
> QueryBatchMessage)}}), that never will be unregistered.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20827) Sql. Remove nullBound placeholder.
[ https://issues.apache.org/jira/browse/IGNITE-20827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich reassigned IGNITE-20827: -- Assignee: Konstantin Orlov > Sql. Remove nullBound placeholder. > --- > > Key: IGNITE-20827 > URL: https://issues.apache.org/jira/browse/IGNITE-20827 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Assignee: Konstantin Orlov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > NullBound placeholder value (BinaryRowConverter::NULL_BOUND) is used to > support for IS NULL / IS NOT DISTINCT FROM operators in search bounds. > Let's remove it in favour of implementaion that does not rely on magic values > to implement aforementated operators. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20829) Remove "basicAuthentication" prefix from JDBC url connection properties
[ https://issues.apache.org/jira/browse/IGNITE-20829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-20829: --- Labels: ignite-3 (was: ) > Remove "basicAuthentication" prefix from JDBC url connection properties > --- > > Key: IGNITE-20829 > URL: https://issues.apache.org/jira/browse/IGNITE-20829 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > It looks confusing for the user to put basicAuthenticationUsername and > basicAuthenticationPassword properties into jdbc connection string. I propose > rename them into username/password. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20780) Sql. Move session expiration to IgniteSqlImpl
[ https://issues.apache.org/jira/browse/IGNITE-20780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782636#comment-17782636 ] Yury Gerzhedovich commented on IGNITE-20780: [~korlov] LGTM! > Sql. Move session expiration to IgniteSqlImpl > - > > Key: IGNITE-20780 > URL: https://issues.apache.org/jira/browse/IGNITE-20780 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > As for now, session management is split between two components: IgniteSql is > responsible for creating new sessions, and sql engine is responsible for > sessions' idle expiration. Let's keep all session management in a single > place: for this we need to move expiration logic to IgniteSqlImpl. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20763) Sql. Clean up query execution
[
https://issues.apache.org/jira/browse/IGNITE-20763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782097#comment-17782097
]
Yury Gerzhedovich commented on IGNITE-20763:
[~korlov] LGTM
> Sql. Clean up query execution
> -
>
> Key: IGNITE-20763
> URL: https://issues.apache.org/jira/browse/IGNITE-20763
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Attachments: flamegraph.html
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> According to flamegraph, QueryTaskExecutor spent more time doing unnecessary
> staff (like instantiating VoidLogger or filling stack traces on happy path
> execution flow) rather than on query itself in case of primitive queries like
> {{SELECT * FROM TABLE(system_range(0, 1))}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20760) Drop column error message get indexes by column name only
[
https://issues.apache.org/jira/browse/IGNITE-20760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781710#comment-17781710
]
Yury Gerzhedovich commented on IGNITE-20760:
[~zstan] could you please review the patch?
> Drop column error message get indexes by column name only
> --
>
> Key: IGNITE-20760
> URL: https://issues.apache.org/jira/browse/IGNITE-20760
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0
>Reporter: Alexander Belyak
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If there are some index, preventing column to be dropped, then error message
> contains all indexes with all columns with the same name. Even if there is
> completely different tables with the same named columns:
> {code:java}
> drop table tab1;
> drop table tab2;
> create table tab1(id integer not null primary key, f1 int);
> create index tab1_f1 on tab1(f1);
> create table tab2(id integer not null primary key, f1 int, f2 int);
> create index tab2_f1 on tab2(f1);
> create index tab2_f12 on tab2(f1,f2);
> alter table tab2 drop column f1;
> >> Fail with wrong error message:
> >> [Code: 0, SQL State: 5] Failed to validate query. Deleting column
> >> 'F1' used by index(es) [TAB1_F1, TAB2_F1, TAB2_F12], it is not allowed
> >> Because it contains TAB1_F1 index
> drop index tab2_f12;
> drop index tab2_f1;
> alter table tab2 drop column f1
> >> Success, so the problem only on the error message generation. {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18662) Sql. Numeric to/from decimal cast with overflow does not produce an error
[
https://issues.apache.org/jira/browse/IGNITE-18662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-18662:
---
Priority: Major (was: Minor)
> Sql. Numeric to/from decimal cast with overflow does not produce an error
> --
>
> Key: IGNITE-18662
> URL: https://issues.apache.org/jira/browse/IGNITE-18662
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Casts from numeric type to decimal with overflow must fail but they return a
> result:
> {code:java}
> SELECT 1000::BIGINT::DECIMAL(3,1)
> {code}
> Returns
> {code:java}
>
> 100
> {code}
> And the following query:
> {code:java}
> SELECT 2147483648::DECIMAL(18,0)::INTEGER
>
> -2147483648
> # Integer.MIN_VALUE
> {code}
> {code:java}
> query I
> SELECT 128::DECIMAL(3,0)::TINYINT
>
> -128
> # Byte.MIN_VALUE
> {code}
> See skipif-ed examples in cast_to_decimal.test and cast_from_decimal.test
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20760) Drop column error message get indexes by column name only
[
https://issues.apache.org/jira/browse/IGNITE-20760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich reassigned IGNITE-20760:
--
Assignee: Yury Gerzhedovich
> Drop column error message get indexes by column name only
> --
>
> Key: IGNITE-20760
> URL: https://issues.apache.org/jira/browse/IGNITE-20760
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0
>Reporter: Alexander Belyak
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> If there are some index, preventing column to be dropped, then error message
> contains all indexes with all columns with the same name. Even if there is
> completely different tables with the same named columns:
> {code:java}
> drop table tab1;
> drop table tab2;
> create table tab1(id integer not null primary key, f1 int);
> create index tab1_f1 on tab1(f1);
> create table tab2(id integer not null primary key, f1 int, f2 int);
> create index tab2_f1 on tab2(f1);
> create index tab2_f12 on tab2(f1,f2);
> alter table tab2 drop column f1;
> >> Fail with wrong error message:
> >> [Code: 0, SQL State: 5] Failed to validate query. Deleting column
> >> 'F1' used by index(es) [TAB1_F1, TAB2_F1, TAB2_F12], it is not allowed
> >> Because it contains TAB1_F1 index
> drop index tab2_f12;
> drop index tab2_f1;
> alter table tab2 drop column f1
> >> Success, so the problem only on the error message generation. {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20764) Sql. Improve script parsing to handle dynamic parameters for each statement
[
https://issues.apache.org/jira/browse/IGNITE-20764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-20764:
---
Component/s: sql
> Sql. Improve script parsing to handle dynamic parameters for each statement
> ---
>
> Key: IGNITE-20764
> URL: https://issues.apache.org/jira/browse/IGNITE-20764
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> At the moment, there is only one implementation ({{ParserServiceImpl}}) of
> the {{ParserService}}, which is not entirely suitable for parsing scripts for
> several reasons:
> 1. According to the {{ParserService}} interface, it returns the result of
> parsing only single statement.
> 2. The service only counts the total number of dynamic parameters per script
> (and not for the statement).
> 3. The cache implementation is designed to cache single expression.
> To implement the script execution logic (IGNITE-20443), it is recommended to
> add a new method (or a second implementation), which will return a list of
> parsing results for each statement (with the correct number of dynamic
> parameters). of the script
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-19813) Unable to execute TPCH Q2 query
[
https://issues.apache.org/jira/browse/IGNITE-19813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich resolved IGNITE-19813.
Resolution: Cannot Reproduce
Seems has been fixed under IGNITE-20714
> Unable to execute TPCH Q2 query
> ---
>
> Key: IGNITE-19813
> URL: https://issues.apache.org/jira/browse/IGNITE-19813
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0
>Reporter: Alexander Belyak
>Priority: Major
> Labels: ignite-3
>
> Executing for standatd TPC-H query Q2 took few minutes. Not work neither as
> Plain test nor PreparedStatement
> {code:java}
> SELECT
> s_acctbal,
> s_name,
> n_name,
> p_partkey,
> p_mfgr,
> s_address,
> s_phone,
> s_comment
> FROM
> part,
> supplier,
> partsupp,
> nation,
> region
> WHERE
> p_partkey = ps_partkey
> AND s_suppkey = ps_suppkey
> AND p_size = 12
> AND p_type LIKE '%NICKEL'
> AND s_nationkey = n_nationkey
> AND n_regionkey = r_regionkey
> AND r_name = 'AFRICA'
> AND ps_supplycost =
> (
> SELECT
> MIN(ps_supplycost)
> FROM
> partsupp,
> supplier,
> nation,
> region
> WHERE
> p_partkey = ps_partkey
> AND s_suppkey = ps_suppkey
> AND s_nationkey = n_nationkey
> AND n_regionkey = r_regionkey
> AND r_name = 'AFRICA'
> )
> ORDER BY
> s_acctbal DESC,
> n_name,
> s_name,
> p_partkey LIMIT 100 {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19619) Term-bases to lease-based switch in SQL engine
[ https://issues.apache.org/jira/browse/IGNITE-19619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-19619: --- Component/s: sql > Term-bases to lease-based switch in SQL engine > --- > > Key: IGNITE-19619 > URL: https://issues.apache.org/jira/browse/IGNITE-19619 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19908) Sql. EXPLAIN should return plan that actually being used for execution
[ https://issues.apache.org/jira/browse/IGNITE-19908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781025#comment-17781025 ] Yury Gerzhedovich commented on IGNITE-19908: [~korlov]LGTM > Sql. EXPLAIN should return plan that actually being used for execution > --- > > Key: IGNITE-19908 > URL: https://issues.apache.org/jira/browse/IGNITE-19908 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently, EXPLAIN query always avoid plan cache, while DML and QUERY plans > are cached. This may cause situation when explain reports more optimal plan > than the one actually being used for execution. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20743) Sql. QueryChecker doesn't check results
[ https://issues.apache.org/jira/browse/IGNITE-20743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779842#comment-17779842 ] Yury Gerzhedovich commented on IGNITE-20743: [~korlov] LGTM > Sql. QueryChecker doesn't check results > --- > > Key: IGNITE-20743 > URL: https://issues.apache.org/jira/browse/IGNITE-20743 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > After IGNITE-20439 query checker had stopped verifying results returned by > query. Let's fix the issue and cover QueryChecker with tests to avoid such > situation in the future. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20712) Incorrect error for any modification queries under RO transaction
[
https://issues.apache.org/jira/browse/IGNITE-20712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779102#comment-17779102
]
Yury Gerzhedovich commented on IGNITE-20712:
[~zstan] [~amashenkov] could you please review the patch?
> Incorrect error for any modification queries under RO transaction
> -
>
> Key: IGNITE-20712
> URL: https://issues.apache.org/jira/browse/IGNITE-20712
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Any DML run under RO transaction lead to INTERNAL Error.
> Obviously DML is prohibited for RO transaction, but instead of internal error
> user should see correct error.
> Current error:
> {code:java}
> org.apache.ignite.sql.SqlException: IGN-CMN-65535
> TraceId:17a52b57-9c70-45b1-b245-17219ab23da5
> at
> org.apache.ignite.internal.lang.SqlExceptionMapperUtil.mapToPublicSqlException(SqlExceptionMapperUtil.java:59)
> at
> org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.wrapIfNecessary(AsyncSqlCursorImpl.java:101)
> at
> org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$requestNextAsync$0(AsyncSqlCursorImpl.java:77)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> at
> java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.closeExecNode(ExecutionServiceImpl.java:954)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.close(ExecutionServiceImpl.java:854)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$onError$2(ExecutionServiceImpl.java:532)
> at
> java.base/java.util.concurrent.CompletableFuture$UniAccept.tryFire(CompletableFuture.java:714)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.executeFragment(ExecutionServiceImpl.java:574)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$submitFragment$9(ExecutionServiceImpl.java:624)
> at
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
> at
> java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:315)
> at
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:81)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20729) Improve AI3 tests
Yury Gerzhedovich created IGNITE-20729: -- Summary: Improve AI3 tests Key: IGNITE-20729 URL: https://issues.apache.org/jira/browse/IGNITE-20729 Project: Ignite Issue Type: Epic Components: sql Reporter: Yury Gerzhedovich -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20728) Sql. improve test coverage for UUID data type
[ https://issues.apache.org/jira/browse/IGNITE-20728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-20728: --- Epic Link: IGNITE-20729 > Sql. improve test coverage for UUID data type > - > > Key: IGNITE-20728 > URL: https://issues.apache.org/jira/browse/IGNITE-20728 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > AI3 have not enough test coverege for UUID data type. > Let's add at least the following: > 1. on basic expression for NOT BETWEEN (as an example need to take > org.apache.ignite.internal.sql.engine.datatypes.tests.BaseExpressionDataTypeTest#testBetweenWithDynamicParameters > / testBetweenWithLiterals ) > 2. Arithmetic operators, string concatenation operators, and other operators > or functions that are not defined on values of UUID data type, should not be > permitted. > 3. We have tests for aggregation functions *count, min, max, any_value, some, > GROUP BY, HAVING*. Other aggregate functions should not be permitted for UUID > 4. Drop an index, check that data is accessible via scan. > 5. Set operations between UUID data type and character types are not legal, > because set operations are allowed only between compatible types. (e.g. > expected error for *SELECT 'a' UNION SELECT '---'::UUID* ) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20728) Sql. improve test coverage for UUID data type
Yury Gerzhedovich created IGNITE-20728: -- Summary: Sql. improve test coverage for UUID data type Key: IGNITE-20728 URL: https://issues.apache.org/jira/browse/IGNITE-20728 Project: Ignite Issue Type: Improvement Components: sql Reporter: Yury Gerzhedovich AI3 have not enough test coverege for UUID data type. Let's add at least the following: 1. on basic expression for NOT BETWEEN (as an example need to take org.apache.ignite.internal.sql.engine.datatypes.tests.BaseExpressionDataTypeTest#testBetweenWithDynamicParameters / testBetweenWithLiterals ) 2. Arithmetic operators, string concatenation operators, and other operators or functions that are not defined on values of UUID data type, should not be permitted. 3. We have tests for aggregation functions *count, min, max, any_value, some, GROUP BY, HAVING*. Other aggregate functions should not be permitted for UUID 4. Drop an index, check that data is accessible via scan. 5. Set operations between UUID data type and character types are not legal, because set operations are allowed only between compatible types. (e.g. expected error for *SELECT 'a' UNION SELECT '---'::UUID* ) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-20233) jdbc: Propagate observable timestamp to sql-engine.
[ https://issues.apache.org/jira/browse/IGNITE-20233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich resolved IGNITE-20233. Resolution: Not A Problem JDBC doesn't keep observable time and works by the same way as embedded client. > jdbc: Propagate observable timestamp to sql-engine. > --- > > Key: IGNITE-20233 > URL: https://issues.apache.org/jira/browse/IGNITE-20233 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > We need to pass the observable timestamp from jdbc client to the sql engine. > This must be done after the completion of IGNITE-19898. > as reference implementation could be used IGNITE-19888 -- This message was sent by Atlassian Jira (v8.20.10#820010)
