[jira] [Updated] (IGNITE-7447) SQL: Wrong BatchUpdateException error code if request fails on remote nod
[
https://issues.apache.org/jira/browse/IGNITE-7447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov updated IGNITE-7447:
---
Summary: SQL: Wrong BatchUpdateException error code if request fails on
remote nod (was: SQL: Wrong {{BatchUpdateException}} error code if request
fails on remote node.)
> SQL: Wrong BatchUpdateException error code if request fails on remote nod
> -
>
> Key: IGNITE-7447
> URL: https://issues.apache.org/jira/browse/IGNITE-7447
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, sql
>Affects Versions: 2.3
>Reporter: Roman Kondakov
>Priority: Major
> Labels: jdbc, sql
>
> If request fails on remote node (i.e. because of the data conversion), we get
> wrong error code in {{BatchUpdateException}}. For example in test
> {{JdbcThinBatchSelfTest#testBatchDeleteExceptionPrepared}} returned code
> should be {{SqlStateCode.CONVERSION_FAILED}} due to wrong argument type, but
> have {{SqlStateCode.INTERNAL_ERROR}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-7447) SQL: Wrong {{BatchUpdateException}} error code if request fails on remote node.
Roman Kondakov created IGNITE-7447:
--
Summary: SQL: Wrong {{BatchUpdateException}} error code if request
fails on remote node.
Key: IGNITE-7447
URL: https://issues.apache.org/jira/browse/IGNITE-7447
Project: Ignite
Issue Type: Bug
Components: jdbc, sql
Affects Versions: 2.3
Reporter: Roman Kondakov
If request fails on remote node (i.e. because of the data conversion), we get
wrong error code in {{BatchUpdateException}}. For example in test
{{JdbcThinBatchSelfTest#testBatchDeleteExceptionPrepared}} returned code should
be {{SqlStateCode.CONVERSION_FAILED}} due to wrong argument type, but have
{{SqlStateCode.INTERNAL_ERROR}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7444) SQL: add native batch execution support for UPDATE, MERGE and DELETE commands
[
https://issues.apache.org/jira/browse/IGNITE-7444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov updated IGNITE-7444:
---
Description: At the moment native batch execution support is implemented
only for {{INSERT}} command. We need to add batching support for other DML
commands. Batching for {{INSERT}} is implemented in IGNITE-6022. (was: At the
moment native batch execution support is implemented only for {{INSERT}}
command. We need to add batching support for other DML commands.)
> SQL: add native batch execution support for UPDATE, MERGE and DELETE commands
> -
>
> Key: IGNITE-7444
> URL: https://issues.apache.org/jira/browse/IGNITE-7444
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.3
>Reporter: Roman Kondakov
>Priority: Major
> Labels: iep-1, performance
>
> At the moment native batch execution support is implemented only for
> {{INSERT}} command. We need to add batching support for other DML commands.
> Batching for {{INSERT}} is implemented in IGNITE-6022.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7444) SQL: add native batch execution support for UPDATE, MERGE and DELETE commands
[
https://issues.apache.org/jira/browse/IGNITE-7444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov updated IGNITE-7444:
---
Description: At the moment native batch execution support is implemented
only for {{INSERT}} command. We need to add batching support for other DML
commands.
> SQL: add native batch execution support for UPDATE, MERGE and DELETE commands
> -
>
> Key: IGNITE-7444
> URL: https://issues.apache.org/jira/browse/IGNITE-7444
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.3
>Reporter: Roman Kondakov
>Priority: Major
> Labels: iep-1, performance
>
> At the moment native batch execution support is implemented only for
> {{INSERT}} command. We need to add batching support for other DML commands.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7444) SQL: add native batch execution support for UPDATE, MERGE and DELETE commands
[
https://issues.apache.org/jira/browse/IGNITE-7444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov updated IGNITE-7444:
---
Environment: (was: At the moment native batch execution support is
implemented only for {{INSERT}} command. We need to add batching support for
other DML commands.)
> SQL: add native batch execution support for UPDATE, MERGE and DELETE commands
> -
>
> Key: IGNITE-7444
> URL: https://issues.apache.org/jira/browse/IGNITE-7444
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.3
>Reporter: Roman Kondakov
>Priority: Major
> Labels: iep-1, performance
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-7444) SQL: add native batch execution support for UPDATE, MERGE and DELETE commands
Roman Kondakov created IGNITE-7444:
--
Summary: SQL: add native batch execution support for UPDATE, MERGE
and DELETE commands
Key: IGNITE-7444
URL: https://issues.apache.org/jira/browse/IGNITE-7444
Project: Ignite
Issue Type: Task
Components: sql
Affects Versions: 2.3
Environment: At the moment native batch execution support is
implemented only for {{INSERT}} command. We need to add batching support for
other DML commands.
Reporter: Roman Kondakov
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6022) SQL: add native batch execution support for DML statements
[
https://issues.apache.org/jira/browse/IGNITE-6022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16327348#comment-16327348
]
Roman Kondakov commented on IGNITE-6022:
[~al.psc], [~vozerov], I changed fields access to getters in {{Batch}} class.
So, {{Batch#rowProcessors}} is used now in {{processPage()}} method.
Logic hadn't been changed after this cosmetics fix, so I didn't restart a TC
run. Please review the patch.
> SQL: add native batch execution support for DML statements
> --
>
> Key: IGNITE-6022
> URL: https://issues.apache.org/jira/browse/IGNITE-6022
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
>Priority: Major
> Labels: iep-1, performance
> Fix For: 2.4
>
>
> We have batch execution support for JDBC and ODBC drivers. This decreases
> number of network hops. However, we do not have any batch execution support
> on the server side. It means that for batch of N similar statements, every
> statement will go through the whole execution chain - parsing, splitting,
> communication with servers. And while parsing and splitting might be avoided
> with help of statement cache, the most heavy part - network communication -
> is still there.
> We need to investigate how to optimize the flow for batch updates. Possible
> improvements:
> 1) Execute statements with certain degree of parallelism;
> 2) Send several query execution requests to the server at once;
> 3) Ensure that caches are used properly for batching - we should not parse
> the same request multiple times.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6022) SQL: add native batch execution support for DML statements
[
https://issues.apache.org/jira/browse/IGNITE-6022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16326428#comment-16326428
]
Roman Kondakov commented on IGNITE-6022:
[~vozerov], [~al.psc], please review. Tests are ok, except one flaky test in
Query 2 suite.
I also found some problem with an SQL wrong error state and error code when
distributed query execution fails on remote nodes. For example in
{{JdbcThinBatchSelfTest#testBatchUpdateExceptionPrepared}} test an error should
be {{SqlStateCode.CONVERSION_FAILED}} (due to wrong value was supplied as an
argument), but we have {{SqlStateCode.INTERNAL_ERROR}}. Should I add a new
ticket for this?
> SQL: add native batch execution support for DML statements
> --
>
> Key: IGNITE-6022
> URL: https://issues.apache.org/jira/browse/IGNITE-6022
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
>Priority: Major
> Labels: iep-1, performance
> Fix For: 2.4
>
>
> We have batch execution support for JDBC and ODBC drivers. This decreases
> number of network hops. However, we do not have any batch execution support
> on the server side. It means that for batch of N similar statements, every
> statement will go through the whole execution chain - parsing, splitting,
> communication with servers. And while parsing and splitting might be avoided
> with help of statement cache, the most heavy part - network communication -
> is still there.
> We need to investigate how to optimize the flow for batch updates. Possible
> improvements:
> 1) Execute statements with certain degree of parallelism;
> 2) Send several query execution requests to the server at once;
> 3) Ensure that caches are used properly for batching - we should not parse
> the same request multiple times.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6022) SQL: add native batch execution support for DML statements
[
https://issues.apache.org/jira/browse/IGNITE-6022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16323886#comment-16323886
]
Roman Kondakov commented on IGNITE-6022:
[~al.psc]
1. Ok, I'll get rid of it.
2. We do not fail on non-SQL exception due to JDBC specs 14.1.3 Handling
Failures during Execution. Briefly: driver should process *all* queries in the
batch despite of any of them failed with *any* reason. If query failed, we mark
it as {{Statement.EXECUTE_FAILED}} at
{{BatchUpdateException.getUpdateCounts}}. So we have to process all queries
even if some of they fail with any exception, and return results of processing
back to the client.
3. Ok, I'll fix it.
4. Ok, I'll fix it.
5. Ok, I'll fix it..
6. Actually, I don't see any reasons for this check in
{{UpdatePlanBuilder.checkPlanCanBeDistributed}}. I'll remove it. [~vozerov], is
it safe to remove it?
7. Ok, I'll fix it.
8. Ok, I'll fix it.
9. Could you please point on such kind of violations? I haven't found any.
10. I agree, I'll add comments.
11. Ok, I'll fix it.
> SQL: add native batch execution support for DML statements
> --
>
> Key: IGNITE-6022
> URL: https://issues.apache.org/jira/browse/IGNITE-6022
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
> Labels: iep-1, performance
> Fix For: 2.4
>
>
> We have batch execution support for JDBC and ODBC drivers. This decreases
> number of network hops. However, we do not have any batch execution support
> on the server side. It means that for batch of N similar statements, every
> statement will go through the whole execution chain - parsing, splitting,
> communication with servers. And while parsing and splitting might be avoided
> with help of statement cache, the most heavy part - network communication -
> is still there.
> We need to investigate how to optimize the flow for batch updates. Possible
> improvements:
> 1) Execute statements with certain degree of parallelism;
> 2) Send several query execution requests to the server at once;
> 3) Ensure that caches are used properly for batching - we should not parse
> the same request multiple times.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6456) Add flags to ClientConnectorConfiguration which enable/disable different clients
[
https://issues.apache.org/jira/browse/IGNITE-6456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16323627#comment-16323627
]
Roman Kondakov commented on IGNITE-6456:
[~ptupitsyn],
* Exceptions look appropriate solution for this case due to multiple possible
causes of failure - wrong client, disabled client or unsupported version. And
exception here is a quite convenient way to stop execution and transfer an
error message back to the client.
* I've fixed error message.
[~vozerov], [~ptupitsyn], please review. [TC
run|https://ci.ignite.apache.org/viewLog.html?buildId=1034773;] is not OK, but
failures are caused by problems in the master branch. JDBC tests are ok.
> Add flags to ClientConnectorConfiguration which enable/disable different
> clients
>
>
> Key: IGNITE-6456
> URL: https://issues.apache.org/jira/browse/IGNITE-6456
> Project: Ignite
> Issue Type: Improvement
> Components: jdbc, odbc, thin client
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Roman Kondakov
> Labels: usability
> Fix For: 2.4
>
>
> There is currently no way to disable only one client. For example, currently
> you can't disallow thin JDBC driver connectivity alone, you can only disable
> the whole {{ClientListenerProcessor}}, which is going to disable ODBC and
> thin .NET clients as well.
> We should add options to disable/enable every single client, supported by the
> {{ClientListenerProcessor}} separately. For example, we can add flags to the
> {{ClientConnectorConfiguration}}:
> {{allowJdbc}}
> {{allowOdbc}}
> {{allowClient}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-6353) Integrate mvcc support in scan query protocol
[ https://issues.apache.org/jira/browse/IGNITE-6353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Kondakov reassigned IGNITE-6353: -- Assignee: Roman Kondakov > Integrate mvcc support in scan query protocol > - > > Key: IGNITE-6353 > URL: https://issues.apache.org/jira/browse/IGNITE-6353 > Project: Ignite > Issue Type: Task > Components: cache >Reporter: Semen Boikov >Assignee: Roman Kondakov > Fix For: 2.5 > > > Need integrate mvcc support in scan query protocol: > - request current ID and list of active txs from coordinator > - pass this info in query requests and in cache iterators > - notify coordinator after query completed -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6772) SQL exception messages are not descriptive
[
https://issues.apache.org/jira/browse/IGNITE-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16322088#comment-16322088
]
Roman Kondakov commented on IGNITE-6772:
[~ptupitsyn],
* This made for an uniformity error messages between different types of JDBC
drivers. JDBC and JDBC2 drivers used to return {{Value is an not instance of "
+ cls.getName()}} in case of types mismatch. JDBC Thin driver returns {{Cannot
convert to URL/boolean/float... etc.}} where type is hardcoded. It is useful
not only for users but also for testing purposes. I'm not sure if we need to
add a source class to the message because this problem is relevant only for
JDBC and JDBC2 drivers which are going to be deprecated as far as I know. Thin
driver {{ResultSet}} includes value (but not value class) in the error message.
E.g. {{"Cannot convert to float: " + val}}. From my point of view it should be
enough for debugging reasons.
* Query text is already included into the exception's message sent from the
parsing engine: {{Column "WRONG" not found; SQL statement: select wrong from
test \[42122-195\]}}. If we also include it here, query will be dublicated in
the same message.
> SQL exception messages are not descriptive
> --
>
> Key: IGNITE-6772
> URL: https://issues.apache.org/jira/browse/IGNITE-6772
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Tupitsyn
>Assignee: Roman Kondakov
> Labels: usability
> Fix For: 2.4
>
>
> Top level SQL exception messages are cryptic and not descriptive. Real
> details are buried deep inside inner exceptions.
> For example, when there is a typo in table name, exception looks like this:
> {code}
> class org.apache.ignite.IgniteCheckedException: Failed to parse query: SELECT
> "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL from Person1,
> "orgs-sql".Organization where Person.OrgId = "orgs-sql".Organization._key and
> "orgs-sql".Organization.Name = ?
> at
> org.apache.ignite.internal.processors.platform.utils.PlatformUtils.unwrapQueryException(PlatformUtils.java:510)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.runQuery(PlatformCache.java:1219)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInStreamOutObject(PlatformCache.java:875)
> at
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutObject(PlatformTargetProxyImpl.java:77)
> Caused by: javax.cache.CacheException: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> parse query: SELECT "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL
> from Person1, "orgs-sql".Organization where Person.OrgId =
> "orgs-sql".Organization._key and "orgs-sql".Organization.Name = ?
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:807)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.runQuery(PlatformCache.java:1213)
> ... 2 more
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> parse query: SELECT "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL
> from Person1, "orgs-sql".Organization where Person.OrgId =
> "orgs-sql".Organization._key and "orgs-sql".Organization.Name = ?
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1293)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSql(IgniteH2Indexing.java:1198)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$8.applyx(GridQueryProcessor.java:1957)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$8.applyx(GridQueryProcessor.java:1955)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2293)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.queryDistributedSql(GridQueryProcessor.java:1954)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySql(GridQueryProcessor.java:1934)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:792)
> ... 3 more
> Caused by: org.h2.jdbc.JdbcSQLException: Table "PERSON1" not found; SQL
> statement:
> SELECT "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL from Person1,
> "orgs-sql".Organization where Person.OrgId = "orgs-sql".Organization._key and
> "orgs-sql".Organization.Name = ? [42102-195]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> at org.h2.message.DbException.get(DbException.java:179)
[jira] [Commented] (IGNITE-6456) Add flags to ClientConnectorConfiguration which enable/disable different clients
[
https://issues.apache.org/jira/browse/IGNITE-6456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16322029#comment-16322029
]
Roman Kondakov commented on IGNITE-6456:
[~ptupitsyn], I refactored this method. Please review. Waiting for [TC
run|https://ci.ignite.apache.org/viewQueued.html?itemId=1033689].
> Add flags to ClientConnectorConfiguration which enable/disable different
> clients
>
>
> Key: IGNITE-6456
> URL: https://issues.apache.org/jira/browse/IGNITE-6456
> Project: Ignite
> Issue Type: Improvement
> Components: jdbc, odbc, thin client
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Roman Kondakov
> Labels: usability
> Fix For: 2.4
>
>
> There is currently no way to disable only one client. For example, currently
> you can't disallow thin JDBC driver connectivity alone, you can only disable
> the whole {{ClientListenerProcessor}}, which is going to disable ODBC and
> thin .NET clients as well.
> We should add options to disable/enable every single client, supported by the
> {{ClientListenerProcessor}} separately. For example, we can add flags to the
> {{ClientConnectorConfiguration}}:
> {{allowJdbc}}
> {{allowOdbc}}
> {{allowClient}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6772) SQL exception messages are not descriptive
[
https://issues.apache.org/jira/browse/IGNITE-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16321875#comment-16321875
]
Roman Kondakov commented on IGNITE-6772:
[~vozerov], [~ptupitsyn], TC run is ok, please review.
> SQL exception messages are not descriptive
> --
>
> Key: IGNITE-6772
> URL: https://issues.apache.org/jira/browse/IGNITE-6772
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Tupitsyn
>Assignee: Roman Kondakov
> Labels: usability
> Fix For: 2.4
>
>
> Top level SQL exception messages are cryptic and not descriptive. Real
> details are buried deep inside inner exceptions.
> For example, when there is a typo in table name, exception looks like this:
> {code}
> class org.apache.ignite.IgniteCheckedException: Failed to parse query: SELECT
> "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL from Person1,
> "orgs-sql".Organization where Person.OrgId = "orgs-sql".Organization._key and
> "orgs-sql".Organization.Name = ?
> at
> org.apache.ignite.internal.processors.platform.utils.PlatformUtils.unwrapQueryException(PlatformUtils.java:510)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.runQuery(PlatformCache.java:1219)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInStreamOutObject(PlatformCache.java:875)
> at
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutObject(PlatformTargetProxyImpl.java:77)
> Caused by: javax.cache.CacheException: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> parse query: SELECT "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL
> from Person1, "orgs-sql".Organization where Person.OrgId =
> "orgs-sql".Organization._key and "orgs-sql".Organization.Name = ?
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:807)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.runQuery(PlatformCache.java:1213)
> ... 2 more
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> parse query: SELECT "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL
> from Person1, "orgs-sql".Organization where Person.OrgId =
> "orgs-sql".Organization._key and "orgs-sql".Organization.Name = ?
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1293)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSql(IgniteH2Indexing.java:1198)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$8.applyx(GridQueryProcessor.java:1957)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$8.applyx(GridQueryProcessor.java:1955)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2293)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.queryDistributedSql(GridQueryProcessor.java:1954)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySql(GridQueryProcessor.java:1934)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:792)
> ... 3 more
> Caused by: org.h2.jdbc.JdbcSQLException: Table "PERSON1" not found; SQL
> statement:
> SELECT "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL from Person1,
> "orgs-sql".Organization where Person.OrgId = "orgs-sql".Organization._key and
> "orgs-sql".Organization.Name = ? [42102-195]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> at org.h2.message.DbException.get(DbException.java:179)
> at org.h2.message.DbException.get(DbException.java:155)
> at org.h2.command.Parser.readTableOrView(Parser.java:5506)
> at org.h2.command.Parser.readTableFilter(Parser.java:1260)
> at org.h2.command.Parser.parseSelectSimpleFromPart(Parser.java:1940)
> at org.h2.command.Parser.parseSelectSimple(Parser.java:2089)
> at org.h2.command.Parser.parseSelectSub(Parser.java:1934)
> at org.h2.command.Parser.parseSelectUnion(Parser.java:1749)
> at org.h2.command.Parser.parseSelect(Parser.java:1737)
> at org.h2.command.Parser.parsePrepared(Parser.java:448)
> at org.h2.command.Parser.parse(Parser.java:320)
> at org.h2.command.Parser.parse(Parser.java:292)
> at org.h2.command.Parser.prepareCommand(Parser.java:257)
> at org.h2.engine.Session.prepareLocal(Session.java:573)
> at org.h2.engine.Session.prepareCommand(Session.java:514)
> at org.h2.jdbc.JdbcConnection.prepareCommand(JdbcConnection.java:1204)
> at
[jira] [Commented] (IGNITE-6456) Add flags to ClientConnectorConfiguration which enable/disable different clients
[
https://issues.apache.org/jira/browse/IGNITE-6456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16320377#comment-16320377
]
Roman Kondakov commented on IGNITE-6456:
[~ptupitsyn], [~vozerov], I fixed the returning version. Please review.
> Add flags to ClientConnectorConfiguration which enable/disable different
> clients
>
>
> Key: IGNITE-6456
> URL: https://issues.apache.org/jira/browse/IGNITE-6456
> Project: Ignite
> Issue Type: Improvement
> Components: jdbc, odbc, thin client
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Roman Kondakov
> Labels: usability
> Fix For: 2.4
>
>
> There is currently no way to disable only one client. For example, currently
> you can't disallow thin JDBC driver connectivity alone, you can only disable
> the whole {{ClientListenerProcessor}}, which is going to disable ODBC and
> thin .NET clients as well.
> We should add options to disable/enable every single client, supported by the
> {{ClientListenerProcessor}} separately. For example, we can add flags to the
> {{ClientConnectorConfiguration}}:
> {{allowJdbc}}
> {{allowOdbc}}
> {{allowClient}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6772) SQL exception messages are not descriptive
[
https://issues.apache.org/jira/browse/IGNITE-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16319796#comment-16319796
]
Roman Kondakov commented on IGNITE-6772:
[~vozerov], [~ptupitsyn], I made a small fix for this problem, please review.
[TC tests|https://ci.ignite.apache.org/viewQueued.html?itemId=1030457] are OK
except some flaky tests in Queries2 suite and .NET tests which depends on the
old error messages. [~ptupitsyn], I think we need to fix these .NET tests.
> SQL exception messages are not descriptive
> --
>
> Key: IGNITE-6772
> URL: https://issues.apache.org/jira/browse/IGNITE-6772
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Tupitsyn
>Assignee: Roman Kondakov
> Labels: usability
> Fix For: 2.4
>
>
> Top level SQL exception messages are cryptic and not descriptive. Real
> details are buried deep inside inner exceptions.
> For example, when there is a typo in table name, exception looks like this:
> {code}
> class org.apache.ignite.IgniteCheckedException: Failed to parse query: SELECT
> "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL from Person1,
> "orgs-sql".Organization where Person.OrgId = "orgs-sql".Organization._key and
> "orgs-sql".Organization.Name = ?
> at
> org.apache.ignite.internal.processors.platform.utils.PlatformUtils.unwrapQueryException(PlatformUtils.java:510)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.runQuery(PlatformCache.java:1219)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInStreamOutObject(PlatformCache.java:875)
> at
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutObject(PlatformTargetProxyImpl.java:77)
> Caused by: javax.cache.CacheException: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> parse query: SELECT "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL
> from Person1, "orgs-sql".Organization where Person.OrgId =
> "orgs-sql".Organization._key and "orgs-sql".Organization.Name = ?
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:807)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.runQuery(PlatformCache.java:1213)
> ... 2 more
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> parse query: SELECT "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL
> from Person1, "orgs-sql".Organization where Person.OrgId =
> "orgs-sql".Organization._key and "orgs-sql".Organization.Name = ?
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1293)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSql(IgniteH2Indexing.java:1198)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$8.applyx(GridQueryProcessor.java:1957)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$8.applyx(GridQueryProcessor.java:1955)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2293)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.queryDistributedSql(GridQueryProcessor.java:1954)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySql(GridQueryProcessor.java:1934)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:792)
> ... 3 more
> Caused by: org.h2.jdbc.JdbcSQLException: Table "PERSON1" not found; SQL
> statement:
> SELECT "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL from Person1,
> "orgs-sql".Organization where Person.OrgId = "orgs-sql".Organization._key and
> "orgs-sql".Organization.Name = ? [42102-195]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> at org.h2.message.DbException.get(DbException.java:179)
> at org.h2.message.DbException.get(DbException.java:155)
> at org.h2.command.Parser.readTableOrView(Parser.java:5506)
> at org.h2.command.Parser.readTableFilter(Parser.java:1260)
> at org.h2.command.Parser.parseSelectSimpleFromPart(Parser.java:1940)
> at org.h2.command.Parser.parseSelectSimple(Parser.java:2089)
> at org.h2.command.Parser.parseSelectSub(Parser.java:1934)
> at org.h2.command.Parser.parseSelectUnion(Parser.java:1749)
> at org.h2.command.Parser.parseSelect(Parser.java:1737)
> at org.h2.command.Parser.parsePrepared(Parser.java:448)
> at org.h2.command.Parser.parse(Parser.java:320)
> at org.h2.command.Parser.parse(Parser.java:292)
> at
[jira] [Commented] (IGNITE-6022) SQL: add native batch execution support for DML statements
[ https://issues.apache.org/jira/browse/IGNITE-6022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16318810#comment-16318810 ] Roman Kondakov commented on IGNITE-6022: [~vozerov], [tests|https://ci.ignite.apache.org/viewLog.html?buildId=1030080;] are ok, please review. > SQL: add native batch execution support for DML statements > -- > > Key: IGNITE-6022 > URL: https://issues.apache.org/jira/browse/IGNITE-6022 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.1 >Reporter: Vladimir Ozerov >Assignee: Roman Kondakov > Labels: iep-1, performance > Fix For: 2.4 > > > We have batch execution support for JDBC and ODBC drivers. This decreases > number of network hops. However, we do not have any batch execution support > on the server side. It means that for batch of N similar statements, every > statement will go through the whole execution chain - parsing, splitting, > communication with servers. And while parsing and splitting might be avoided > with help of statement cache, the most heavy part - network communication - > is still there. > We need to investigate how to optimize the flow for batch updates. Possible > improvements: > 1) Execute statements with certain degree of parallelism; > 2) Send several query execution requests to the server at once; > 3) Ensure that caches are used properly for batching - we should not parse > the same request multiple times. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6022) SQL: add native batch execution support for DML statements
[ https://issues.apache.org/jira/browse/IGNITE-6022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16318473#comment-16318473 ] Roman Kondakov commented on IGNITE-6022: [~vozerov], tests are OK, please review. > SQL: add native batch execution support for DML statements > -- > > Key: IGNITE-6022 > URL: https://issues.apache.org/jira/browse/IGNITE-6022 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.1 >Reporter: Vladimir Ozerov >Assignee: Roman Kondakov > Labels: iep-1, performance > Fix For: 2.4 > > > We have batch execution support for JDBC and ODBC drivers. This decreases > number of network hops. However, we do not have any batch execution support > on the server side. It means that for batch of N similar statements, every > statement will go through the whole execution chain - parsing, splitting, > communication with servers. And while parsing and splitting might be avoided > with help of statement cache, the most heavy part - network communication - > is still there. > We need to investigate how to optimize the flow for batch updates. Possible > improvements: > 1) Execute statements with certain degree of parallelism; > 2) Send several query execution requests to the server at once; > 3) Ensure that caches are used properly for batching - we should not parse > the same request multiple times. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6456) Add flags to ClientConnectorConfiguration which enable/disable different clients
[
https://issues.apache.org/jira/browse/IGNITE-6456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16318437#comment-16318437
]
Roman Kondakov commented on IGNITE-6456:
I've added more informative error messages as [~ptupitsyn] advised.
> Add flags to ClientConnectorConfiguration which enable/disable different
> clients
>
>
> Key: IGNITE-6456
> URL: https://issues.apache.org/jira/browse/IGNITE-6456
> Project: Ignite
> Issue Type: Improvement
> Components: jdbc, odbc, thin client
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Roman Kondakov
> Labels: usability
> Fix For: 2.4
>
>
> There is currently no way to disable only one client. For example, currently
> you can't disallow thin JDBC driver connectivity alone, you can only disable
> the whole {{ClientListenerProcessor}}, which is going to disable ODBC and
> thin .NET clients as well.
> We should add options to disable/enable every single client, supported by the
> {{ClientListenerProcessor}} separately. For example, we can add flags to the
> {{ClientConnectorConfiguration}}:
> {{allowJdbc}}
> {{allowOdbc}}
> {{allowClient}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6456) Add flags to ClientConnectorConfiguration which enable/disable different clients
[
https://issues.apache.org/jira/browse/IGNITE-6456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16306262#comment-16306262
]
Roman Kondakov commented on IGNITE-6456:
[~vozerov], [~isapego], [~ptupitsyn], please review. And if patch is ok, please
add relevant changes to the other platforms.
[TC run|https://ci.ignite.apache.org/viewLog.html?buildId=1024378;] is almost
OK, except
{{ClientConnectorConfigurationParityTest.TestConnectorConfiguration}} in .NET
suite which was expected configuration API changes, and some flaky tests in
Queries2 suite.
> Add flags to ClientConnectorConfiguration which enable/disable different
> clients
>
>
> Key: IGNITE-6456
> URL: https://issues.apache.org/jira/browse/IGNITE-6456
> Project: Ignite
> Issue Type: Improvement
> Components: jdbc, odbc, thin client
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Roman Kondakov
> Labels: usability
> Fix For: 2.4
>
>
> There is currently no way to disable only one client. For example, currently
> you can't disallow thin JDBC driver connectivity alone, you can only disable
> the whole {{ClientListenerProcessor}}, which is going to disable ODBC and
> thin .NET clients as well.
> We should add options to disable/enable every single client, supported by the
> {{ClientListenerProcessor}} separately. For example, we can add flags to the
> {{ClientConnectorConfiguration}}:
> {{allowJdbc}}
> {{allowOdbc}}
> {{allowClient}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6022) SQL: add native batch execution support for DML statements
[
https://issues.apache.org/jira/browse/IGNITE-6022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16305147#comment-16305147
]
Roman Kondakov commented on IGNITE-6022:
[~vozerov], my comments:
1) I agree. I'll add this test.
2) Concerning flushing all batches on duplicates found - I agree it's not
efficient, I'll change this behavior into flushing only the affected batch.
Concerning replacing a {{Map cntPerRow}} with an array. I
think it is not a good idea because we do not know the total size of the rows
we need to update on {{DmlBatchSender}} creation stage. We have only cursor
which allows to iterate over these rows. So, we have to manage the array size
manually and extend it on demand. But it is possible to replace the {{Map}}
with an {{ArrayList}}. I'm not sure it is much more efficient and easier to
implement than a map, but I agree that if we have a range of integer keys from
{{0}} to {{N}} it better to use array-like structures than map. I'll replace
map with an {{ArrayList}}.
3) I'll remove this method.
4) I agree. I'll add tests with various scenarios in {{JdbcThinBatchSelfTest}}.
Or should I add these tests not only for thin driver, but also for all Ignite
JDBC driver types?
> SQL: add native batch execution support for DML statements
> --
>
> Key: IGNITE-6022
> URL: https://issues.apache.org/jira/browse/IGNITE-6022
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
> Labels: iep-1, performance
> Fix For: 2.4
>
>
> We have batch execution support for JDBC and ODBC drivers. This decreases
> number of network hops. However, we do not have any batch execution support
> on the server side. It means that for batch of N similar statements, every
> statement will go through the whole execution chain - parsing, splitting,
> communication with servers. And while parsing and splitting might be avoided
> with help of statement cache, the most heavy part - network communication -
> is still there.
> We need to investigate how to optimize the flow for batch updates. Possible
> improvements:
> 1) Execute statements with certain degree of parallelism;
> 2) Send several query execution requests to the server at once;
> 3) Ensure that caches are used properly for batching - we should not parse
> the same request multiple times.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6904) SQL: partition reservations are released too early in lazy mode
[
https://issues.apache.org/jira/browse/IGNITE-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16303161#comment-16303161
]
Roman Kondakov commented on IGNITE-6904:
[~vozerov], this is a cursor close case. And therefore as in the case of query
canceling it should be treated in the same manner - all reservations should be
released despite of the query type.
> SQL: partition reservations are released too early in lazy mode
> ---
>
> Key: IGNITE-6904
> URL: https://issues.apache.org/jira/browse/IGNITE-6904
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
> Fix For: 2.4
>
>
> In lazy mode we advance query execution as new page requests arrive. However,
> method {{GridMapQueryExecutor#onQueryRequest0}} releases partition
> reservations when only the very first page is processed:
> {code}
> finally {
> GridH2QueryContext.clearThreadLocal();
> if (distributedJoinMode == OFF)
> qctx.clearContext(false);
> }
> {code}
> It means that incorrect results may be returned on unstable topology. We need
> to release partitions only after the whole query is executed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6785) Affinity field name forced to be upper-case
[
https://issues.apache.org/jira/browse/IGNITE-6785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16296528#comment-16296528
]
Roman Kondakov commented on IGNITE-6785:
[~vozerov], please review, tests are ok.
> Affinity field name forced to be upper-case
> ---
>
> Key: IGNITE-6785
> URL: https://issues.apache.org/jira/browse/IGNITE-6785
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.1
>Reporter: Denis Magda
>Assignee: Roman Kondakov
> Labels: important, usability
> Fix For: 2.4
>
> Attachments: sql_bug.zip
>
>
> If an SQL schema and cache is created with CREATE TABLE command and a user
> wants to use key-value APIs creating its own custom key class, then (at
> least) the key class's affinity field forced to be written in upper-case.
> Steps to reproduce using the project attached:
> * start a node with {{./ignite.sh ../examples/config/example-ignite.xml}}.
> * create {{City}} table using {{ignite_world.sql}}. SQLline is one of the
> quickest ways: https://apacheignite-sql.readme.io/docs/sqlline
> * Run {{KeyValueDataProcessing}} to catch the exception below
> {noformat}
> Exception in thread "main" class
> org.apache.ignite.binary.BinaryObjectException: Binary type has different
> affinity key fields [typeName=demo.model.CityKey,
> affKeyFieldName1=COUNTRYCODE, affKeyFieldName2=countryCode]
> at
> org.apache.ignite.internal.binary.BinaryUtils.mergeMetadata(BinaryUtils.java:987)
> {noformat}
> If fact {{CityKey}} names the affinity field in the same way as in CREATE
> TABLE - {{countryCode}}.
> Next, run {{KeyValueBinaryDataProcessing}} to spot another weird thing:
> * BinaryObject key accepts `countryCode` as the affinity field name.
> * If to print our a binary object value then all the fields are in the
> upper-case (they were not defined this way in CREATE TABLE):
> {noformat}
> demo.model.City [idHash=1613627715, hash=-1386587499, DISTRICT=Noord-Holland,
> POPULATION=711200, NAME=Amsterdam]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-6785) Affinity field name forced to be upper-case
[
https://issues.apache.org/jira/browse/IGNITE-6785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov reassigned IGNITE-6785:
--
Assignee: Roman Kondakov (was: Vladimir Ozerov)
> Affinity field name forced to be upper-case
> ---
>
> Key: IGNITE-6785
> URL: https://issues.apache.org/jira/browse/IGNITE-6785
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.1
>Reporter: Denis Magda
>Assignee: Roman Kondakov
> Labels: important, usability
> Fix For: 2.4
>
> Attachments: sql_bug.zip
>
>
> If an SQL schema and cache is created with CREATE TABLE command and a user
> wants to use key-value APIs creating its own custom key class, then (at
> least) the key class's affinity field forced to be written in upper-case.
> Steps to reproduce using the project attached:
> * start a node with {{./ignite.sh ../examples/config/example-ignite.xml}}.
> * create {{City}} table using {{ignite_world.sql}}. SQLline is one of the
> quickest ways: https://apacheignite-sql.readme.io/docs/sqlline
> * Run {{KeyValueDataProcessing}} to catch the exception below
> {noformat}
> Exception in thread "main" class
> org.apache.ignite.binary.BinaryObjectException: Binary type has different
> affinity key fields [typeName=demo.model.CityKey,
> affKeyFieldName1=COUNTRYCODE, affKeyFieldName2=countryCode]
> at
> org.apache.ignite.internal.binary.BinaryUtils.mergeMetadata(BinaryUtils.java:987)
> {noformat}
> If fact {{CityKey}} names the affinity field in the same way as in CREATE
> TABLE - {{countryCode}}.
> Next, run {{KeyValueBinaryDataProcessing}} to spot another weird thing:
> * BinaryObject key accepts `countryCode` as the affinity field name.
> * If to print our a binary object value then all the fields are in the
> upper-case (they were not defined this way in CREATE TABLE):
> {noformat}
> demo.model.City [idHash=1613627715, hash=-1386587499, DISTRICT=Noord-Holland,
> POPULATION=711200, NAME=Amsterdam]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-7015) SQL: index should be updated only when relevant values changed
[
https://issues.apache.org/jira/browse/IGNITE-7015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16294317#comment-16294317
]
Roman Kondakov commented on IGNITE-7015:
[~vozerov], I optimized my patch as you wrote in a comment above. A set of the
indexed columns was added to {{GridH2Table}}. This set is changed on each index
add/remove action. Temporary indexes are considered as normal indexes in this
case. All comparison logic moved to {{GridH2Table}}.
As for {{GridQueryProcessor.store}} invocation - I went through the code
execution in case of in-place update is possible and made sure that
{{GridQueryProcessor.store}} is not executed in this case because in the method
{{GridCacheMapEntry.AtomicCacheUpdateClosure#update}} we can see this snippet:
{code:java}
treeOp = oldRow != null && oldRow.link() == newRow.link() ?
IgniteTree.OperationType.NOOP :
IgniteTree.OperationType.PUT;
{code}
which is responsible for a choosing further tree operation after the closure
update. And if rows links are equal (which is true for in-place update), the
{{NOOP}} is chosen and therefore methods {{CacheDataStoreImpl#finishUpdate}}
and {{GridQueryProcessor#store}} are not called in
{{CacheDataStoreImpl#invoke}}.
TC tests are OK. Please review.
> SQL: index should be updated only when relevant values changed
> --
>
> Key: IGNITE-7015
> URL: https://issues.apache.org/jira/browse/IGNITE-7015
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
> Labels: iep-1, performance
> Fix For: 2.4
>
>
> See {{GridH2Table.update}} method. Whenever value is updated, we propagate it
> to all indexes. Consider the following case:
> 1) Old row is not null, so this is "update", not "create".
> 2) Link hasn't changed
> 3) Indexed fields haven't changed
> If all conditions are met, we can skip index update completely, as state
> before and after will be the same. This is especially important when
> persistence is enabled because currently we generate unnecessary dirty pages
> what increases IO pressure.
> Suggested fix:
> 1) Iterate over index columns, skipping key and affinity columns (as they are
> guaranteed to be the same);
> 2) Compare relevant index columns of both old and new rows
> 3) If all columns are equal, do nothing.
> Fields should be read through {{GridH2KeyValueRowOnheap#getValue}}, because
> in this case we will re-use value cache transparently.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-7039) SQL: local query should pin affected partitions
[
https://issues.apache.org/jira/browse/IGNITE-7039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16292167#comment-16292167
]
Roman Kondakov edited comment on IGNITE-7039 at 12/15/17 9:20 AM:
--
[~vozerov], please review.
1) In {{IgniteH2Indexing.queryLocalSqlFields}} I implemented an eager
partitions reservation on {{IgniteCache.query()}} call. I also implemented a
test {{IgniteCacheLocalQueryReservationsTest}} for checking a partitions
reservation status on each stage:
* Before {{IgniteCache.query()}}.
* After {{IgniteCache.query()}}.
* After {{QueryCursor.iterator()}}.
* After {{Iterator.next()}}.
* After {{QueryCursor.close()}}.
2) I implemented another method for a gathering all caches ids used in a query
based on {{GridSqlQueryParser}}. I also added a cache map for the parsed
queries.
was (Author: rkondakov):
[~vozerov], please review.
1) In {{IgniteH2Indexing.queryLocalSqlFields}} I implemented an eager
partitions reservation on {{IgniteCache.query()}} call. I also implemented a
test {{IgniteCacheLocalQueryReservationsTest}} for checking a partitions
reservation status on each stage:
* Before {{IgniteCache.query()}}.
* After {{IgniteCache.query()}}.
* After {{QueryCursor.iterator()}}.
* After {{Iterator.next()}}.
* After {{QueryCursor.close()}}.
2. I implemented another method for a gathering all caches ids used in a query
based on {{GridSqlQueryParser}}. I also added a cache map for the parsed
queries.
> SQL: local query should pin affected partitions
> ---
>
> Key: IGNITE-7039
> URL: https://issues.apache.org/jira/browse/IGNITE-7039
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
> Fix For: 2.4
>
>
> When distributed query is executed, we pin cache partitions for particular
> topology version on map nodes [1]. However, it seems that we do no do that
> for local queries. This is a bug because partition with required data could
> be evicted from local node at any time, leading to incorrect results.
> [1]
> https://github.com/apache/ignite/blob/ignite-2.3/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/twostep/GridMapQueryExecutor.java#L288
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-7039) SQL: local query should pin affected partitions
[
https://issues.apache.org/jira/browse/IGNITE-7039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16292167#comment-16292167
]
Roman Kondakov commented on IGNITE-7039:
[~vozerov], please review.
1) In {{IgniteH2Indexing.queryLocalSqlFields}} I implemented an eager
partitions reservation on {{IgniteCache.query()}} call. I also implemented a
test {{IgniteCacheLocalQueryReservationsTest}} for checking a partitions
reservation status on each stage:
* Before {{IgniteCache.query()}}.
* After {{IgniteCache.query()}}.
* After {{QueryCursor.iterator()}}.
* After {{Iterator.next()}}.
* After {{QueryCursor.close()}}.
2. I implemented another method for a gathering all caches ids used in a query
based on {{GridSqlQueryParser}}. I also added a cache map for the parsed
queries.
> SQL: local query should pin affected partitions
> ---
>
> Key: IGNITE-7039
> URL: https://issues.apache.org/jira/browse/IGNITE-7039
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
> Fix For: 2.4
>
>
> When distributed query is executed, we pin cache partitions for particular
> topology version on map nodes [1]. However, it seems that we do no do that
> for local queries. This is a bug because partition with required data could
> be evicted from local node at any time, leading to incorrect results.
> [1]
> https://github.com/apache/ignite/blob/ignite-2.3/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/twostep/GridMapQueryExecutor.java#L288
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-7039) SQL: local query should pin affected partitions
[ https://issues.apache.org/jira/browse/IGNITE-7039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16285825#comment-16285825 ] Roman Kondakov commented on IGNITE-7039: [~vozerov], please review, tests are ok. > SQL: local query should pin affected partitions > --- > > Key: IGNITE-7039 > URL: https://issues.apache.org/jira/browse/IGNITE-7039 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Vladimir Ozerov >Assignee: Roman Kondakov > > When distributed query is executed, we pin cache partitions for particular > topology version on map nodes [1]. However, it seems that we do no do that > for local queries. This is a bug because partition with required data could > be evicted from local node at any time, leading to incorrect results. > [1] > https://github.com/apache/ignite/blob/ignite-2.3/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/twostep/GridMapQueryExecutor.java#L288 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6904) SQL: partition reservations are released too early in lazy mode
[
https://issues.apache.org/jira/browse/IGNITE-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16285586#comment-16285586
]
Roman Kondakov commented on IGNITE-6904:
[~skalashnikov], [~vozerov], I've added a test for the checking if the
partition reservations are released after the cursor having been closed.
Actually, reservations have not been released in this case and test revealed
this problem. I added a fix for this also.
Please, review. TC run is ok.
> SQL: partition reservations are released too early in lazy mode
> ---
>
> Key: IGNITE-6904
> URL: https://issues.apache.org/jira/browse/IGNITE-6904
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
> Fix For: 2.4
>
>
> In lazy mode we advance query execution as new page requests arrive. However,
> method {{GridMapQueryExecutor#onQueryRequest0}} releases partition
> reservations when only the very first page is processed:
> {code}
> finally {
> GridH2QueryContext.clearThreadLocal();
> if (distributedJoinMode == OFF)
> qctx.clearContext(false);
> }
> {code}
> It means that incorrect results may be returned on unstable topology. We need
> to release partitions only after the whole query is executed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-7139) SQL: Implement a lazy execution for the local queries.
Roman Kondakov created IGNITE-7139:
--
Summary: SQL: Implement a lazy execution for the local queries.
Key: IGNITE-7139
URL: https://issues.apache.org/jira/browse/IGNITE-7139
Project: Ignite
Issue Type: Improvement
Components: sql
Affects Versions: 2.3
Reporter: Roman Kondakov
Fix For: 2.4
At the moment a lazy execution is implemented for the distributed queries only
(see {{GridMapQueryExecutor}}). We need to add this feature for the local
queries too.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-7044) SQL: Documentation for the PARALLEL statement in the CREATE INDEX command
[ https://issues.apache.org/jira/browse/IGNITE-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16281442#comment-16281442 ] Roman Kondakov commented on IGNITE-7044: [~dmagda], IMHO yes, they have quite similar semantics. But they used for the different types of queries - SQL and DDL. [~vozerov], what do you think? > SQL: Documentation for the PARALLEL statement in the CREATE INDEX command > - > > Key: IGNITE-7044 > URL: https://issues.apache.org/jira/browse/IGNITE-7044 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.1 >Reporter: Roman Kondakov >Assignee: Roman Kondakov > Fix For: 2.4 > > > Add a documentation for the PARALLEL option in the CREATE INDEX command. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-7015) SQL: index should be updated only when relevant values changed
[
https://issues.apache.org/jira/browse/IGNITE-7015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16280556#comment-16280556
]
Roman Kondakov commented on IGNITE-7015:
[~vozerov] please review, tests are OK.
> SQL: index should be updated only when relevant values changed
> --
>
> Key: IGNITE-7015
> URL: https://issues.apache.org/jira/browse/IGNITE-7015
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
> Labels: iep-1, performance
> Fix For: 2.4
>
>
> See {{GridH2Table.update}} method. Whenever value is updated, we propagate it
> to all indexes. Consider the following case:
> 1) Old row is not null, so this is "update", not "create".
> 2) Link hasn't changed
> 3) Indexed fields haven't changed
> If all conditions are met, we can skip index update completely, as state
> before and after will be the same. This is especially important when
> persistence is enabled because currently we generate unnecessary dirty pages
> what increases IO pressure.
> Suggested fix:
> 1) Iterate over index columns, skipping key and affinity columns (as they are
> guaranteed to be the same);
> 2) Compare relevant index columns of both old and new rows
> 3) If all columns are equal, do nothing.
> Fields should be read through {{GridH2KeyValueRowOnheap#getValue}}, because
> in this case we will re-use value cache transparently.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-7039) SQL: local query should pin affected partitions
[ https://issues.apache.org/jira/browse/IGNITE-7039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Kondakov reassigned IGNITE-7039: -- Assignee: Roman Kondakov > SQL: local query should pin affected partitions > --- > > Key: IGNITE-7039 > URL: https://issues.apache.org/jira/browse/IGNITE-7039 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Vladimir Ozerov >Assignee: Roman Kondakov > > When distributed query is executed, we pin cache partitions for particular > topology version on map nodes [1]. However, it seems that we do no do that > for local queries. This is a bug because partition with required data could > be evicted from local node at any time, leading to incorrect results. > [1] > https://github.com/apache/ignite/blob/ignite-2.3/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/twostep/GridMapQueryExecutor.java#L288 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6343) Index is not used properly if changing sort order.
[
https://issues.apache.org/jira/browse/IGNITE-6343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov reassigned IGNITE-6343:
--
Assignee: Roman Kondakov
> Index is not used properly if changing sort order.
> --
>
> Key: IGNITE-6343
> URL: https://issues.apache.org/jira/browse/IGNITE-6343
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.0
>Reporter: Alexei Scherbakov
>Assignee: Roman Kondakov
> Labels: performance
>
> Unit test reproducer:
> {noformat}
> /*
> * Licensed to the Apache Software Foundation (ASF) under one or more
> * contributor license agreements. See the NOTICE file distributed with
> * this work for additional information regarding copyright ownership.
> * The ASF licenses this file to You under the Apache License, Version 2.0
> * (the "License"); you may not use this file except in compliance with
> * the License. You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
> package org.apache.ignite.internal.processors.cache;
> import java.util.Calendar;
> import java.util.Collections;
> import java.util.Date;
> import java.util.LinkedHashMap;
> import java.util.List;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.QueryEntity;
> import org.apache.ignite.cache.QueryIndex;
> import org.apache.ignite.cache.QueryIndexType;
> import org.apache.ignite.cache.query.SqlFieldsQuery;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.configuration.MemoryConfiguration;
> import org.apache.ignite.configuration.MemoryPolicyConfiguration;
> import org.apache.ignite.internal.util.typedef.internal.U;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.TcpDiscoveryIpFinder;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import static org.apache.ignite.cache.CacheMode.PARTITIONED;
> import static org.apache.ignite.cache.CacheWriteSynchronizationMode.FULL_SYNC;
> import static java.util.Calendar.*;
> /**
> * Tests for cache query results serialization.
> */
> public class GridCacheQueryIndexUsageSelfTest extends GridCommonAbstractTest {
> /** */
> private static final int GRID_CNT = 1;
> /** */
> private static final String CACHE_NAME = "A";
> /** */
> private static final CacheMode CACHE_MODE = PARTITIONED;
> /** */
> private static TcpDiscoveryIpFinder ipFinder = new
> TcpDiscoveryVmIpFinder(true);
> /** {@inheritDoc} */
> @Override protected void beforeTest() throws Exception {
> startGridsMultiThreaded(GRID_CNT);
> }
> /** {@inheritDoc} */
> @Override protected void afterTest() throws Exception {
> stopAllGrids();
> }
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> MemoryPolicyConfiguration mpcfg = new MemoryPolicyConfiguration();
> //mpcfg.setMaxSize(2 * 1024 * 1024 * 1024L);
> mpcfg.setName("def");
> MemoryConfiguration mcfg = new MemoryConfiguration();
> mcfg.setDefaultMemoryPolicyName("def");
> mcfg.setMemoryPolicies(mpcfg);
> cfg.setMemoryConfiguration(mcfg);
> TcpDiscoverySpi disco = new TcpDiscoverySpi();
> disco.setIpFinder(ipFinder);
> cfg.setDiscoverySpi(disco);
> CacheConfiguration cacheCfg = defaultCacheConfiguration();
> cacheCfg.setName(CACHE_NAME);
> cacheCfg.setCacheMode(CACHE_MODE);
> cacheCfg.setWriteSynchronizationMode(FULL_SYNC);
> QueryEntity qe = new QueryEntity();
> qe.setKeyType(Long.class.getName());
> qe.setValueType(IndexedValue.class.getName());
> LinkedHashMap fields = U.newLinkedHashMap(3);
> fields.put("id", Long.class.getName());
> fields.put("startDate", Date.class.getName());
> qe.setFields(fields);
> QueryIndex idx = new QueryIndex();
> idx.setIndexType(QueryIndexType.SORTED);
> LinkedHashMap idxFields =
[jira] [Created] (IGNITE-7120) Test cases inherited by AbstractSchemaSelfTest became flucky after the refactoring to use SQL API.
Roman Kondakov created IGNITE-7120:
--
Summary: Test cases inherited by AbstractSchemaSelfTest became
flucky after the refactoring to use SQL API.
Key: IGNITE-7120
URL: https://issues.apache.org/jira/browse/IGNITE-7120
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.3
Reporter: Roman Kondakov
Fix For: 2.4
This problem may be caused by the delay between CREATE INDEX command and the
consequitive JDBC metadata updating. Therefore, a metadata info may be
outdated in AbstractSchemaSelfTest#assertIndex() {..
c.getMetaData().getIndexInfo() ..}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-7044) SQL: Documentation for the PARALLEL statement in the CREATE INDEX command
[ https://issues.apache.org/jira/browse/IGNITE-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16270346#comment-16270346 ] Roman Kondakov commented on IGNITE-7044: [~dmagda], [~pgarg], please review the documentation for the PARALLEL option in the CREATE INDEX command: https://dash.readme.io/project/apacheignite-sql/v2.3/docs/create-index_24_hidden > SQL: Documentation for the PARALLEL statement in the CREATE INDEX command > - > > Key: IGNITE-7044 > URL: https://issues.apache.org/jira/browse/IGNITE-7044 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.1 >Reporter: Roman Kondakov >Assignee: Denis Magda > Fix For: 2.4 > > > Add a documentation for the PARALLEL option in the CREATE INDEX command. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-7044) SQL: Documentation for the PARALLEL statement in the CREATE INDEX command
[ https://issues.apache.org/jira/browse/IGNITE-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Kondakov updated IGNITE-7044: --- External issue URL: (was: https://issues.apache.org/jira/browse/IGNITE-6406) > SQL: Documentation for the PARALLEL statement in the CREATE INDEX command > - > > Key: IGNITE-7044 > URL: https://issues.apache.org/jira/browse/IGNITE-7044 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.1 >Reporter: Roman Kondakov >Assignee: Roman Kondakov > Fix For: 2.4 > > > Add a documentation for the PARALLEL option in the CREATE INDEX command. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7044) SQL: Documentation for the PARALLEL statement in the CREATE INDEX command
Roman Kondakov created IGNITE-7044: -- Summary: SQL: Documentation for the PARALLEL statement in the CREATE INDEX command Key: IGNITE-7044 URL: https://issues.apache.org/jira/browse/IGNITE-7044 Project: Ignite Issue Type: Task Components: documentation Affects Versions: 2.1 Reporter: Roman Kondakov Assignee: Roman Kondakov Fix For: 2.4 Add a documentation for the PARALLEL option in the CREATE INDEX command. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6406) SQL: CREATE INDEX should fill index from multiple threads
[
https://issues.apache.org/jira/browse/IGNITE-6406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16266892#comment-16266892
]
Roman Kondakov commented on IGNITE-6406:
[~vozerov] please review, tests are ok.
> SQL: CREATE INDEX should fill index from multiple threads
> -
>
> Key: IGNITE-6406
> URL: https://issues.apache.org/jira/browse/IGNITE-6406
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
> Labels: iep-1, performance
> Fix For: 2.4
>
>
> Currently when {{CREATE INDEX}} command is executed, we fill new index from a
> single thread. Low CPU, long create time. We can trade off CPU vs time by
> adding more threads.
> Probably number of threads should be specified in {{CREATE INDEX}} command as
> a hint.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6085) SQL: JOIN with multiple conditions is extremely slow
[
https://issues.apache.org/jira/browse/IGNITE-6085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16265020#comment-16265020
]
Roman Kondakov commented on IGNITE-6085:
After the deep research it was found out that such kind of problems occurs not
only in the JOIN statements, but also in any SELECT ... WHERE statement with
the OR clause. For example, in this query H2 will use the full table scan
instead of indexes, which could lead to unacceptable execution time:
{code}
SELECT * FROM tbl WHERE field1=1 OR field2=2
{code}
H2 does not use indexes here because if it iterate over the index on the field1
with the value 1, it would not get all rows with the field2=2 because not all
rows with field2=2 have also field1=1. So, to obtain a correct result set using
indexes, H2 should iterate over the index on field1 with the condition field1=1
and also iterate over the index on field2 with the condition field2=2. And then
merge both results fetched during these iterations. But this scenario is not
implemented in H2 yet, so it uses a full scan instead of the indexes in the OR
clauses.
There is a TODO comment in org.h2.expression.ConditionAndOr (since 2008):
{code:java}
// TODO optimization: convert .. OR .. to UNION if the cost is lower
{code}
After this optimization in the H2 engine has been done, this ticket can be
closed.
> SQL: JOIN with multiple conditions is extremely slow
>
>
> Key: IGNITE-6085
> URL: https://issues.apache.org/jira/browse/IGNITE-6085
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
> Labels: performance
> Fix For: 2.4
>
>
> Consider the following query:
> {code}
> SELECT ... FROM A a
> INNER JOIN B b ON b.id = a.foreign_id1 OR b.id = a.foreign_id2
> {code}
> In this case H2 cannot use indexes on {{foreign_id1}} or {{foreign_id2}}
> columns and query execution takes extraordinary time. Known workaround for a
> problem is to apply multiple JOINs, e.g.:
> {code}
> SELECT ... FROM A a
> LEFT OUTER JOIN B b1 ON b1.id = a.foreign_id1
> LEFT OUTER JOIN B b2 ON b2.id = a.foreign_id2
> WHERE b1.id IS NOT NULL AND b2.id IS NOT NULL
> {code}
> On a single real-world scenario it improved exeution time by a factor of 500
> (from 4s to 80ms).
> Something is terribly wrong here. Probably, H2 cannot perform necessary query
> re-write, or cannot understand how to use index. Let's find a way to fix that.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6904) SQL: partition reservations are released too early in lazy mode
[
https://issues.apache.org/jira/browse/IGNITE-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16263886#comment-16263886
]
Roman Kondakov commented on IGNITE-6904:
[~vozerov], please review. Tests are ok.
> SQL: partition reservations are released too early in lazy mode
> ---
>
> Key: IGNITE-6904
> URL: https://issues.apache.org/jira/browse/IGNITE-6904
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
> Fix For: 2.4
>
>
> In lazy mode we advance query execution as new page requests arrive. However,
> method {{GridMapQueryExecutor#onQueryRequest0}} releases partition
> reservations when only the very first page is processed:
> {code}
> finally {
> GridH2QueryContext.clearThreadLocal();
> if (distributedJoinMode == OFF)
> qctx.clearContext(false);
> }
> {code}
> It means that incorrect results may be returned on unstable topology. We need
> to release partitions only after the whole query is executed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6406) SQL: CREATE INDEX should fill index from multiple threads
[
https://issues.apache.org/jira/browse/IGNITE-6406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16259248#comment-16259248
]
Roman Kondakov commented on IGNITE-6406:
[~vozerov] please review. Tests are OK.
> SQL: CREATE INDEX should fill index from multiple threads
> -
>
> Key: IGNITE-6406
> URL: https://issues.apache.org/jira/browse/IGNITE-6406
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
> Labels: iep-1, performance
> Fix For: 2.4
>
>
> Currently when {{CREATE INDEX}} command is executed, we fill new index from a
> single thread. Low CPU, long create time. We can trade off CPU vs time by
> adding more threads.
> Probably number of threads should be specified in {{CREATE INDEX}} command as
> a hint.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6085) SQL: JOIN with multiple conditions is extremely slow
[
https://issues.apache.org/jira/browse/IGNITE-6085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255155#comment-16255155
]
Roman Kondakov commented on IGNITE-6085:
This problem occurs only with the OR condition in ON clause. If you change
condition to AND this query works well. The problem could be in the method
{code:java}
public void createIndexConditions(Session session, TableFilter filter) {
if (andOrType == AND) {
left.createIndexConditions(session, filter);
right.createIndexConditions(session, filter);
}
}
{code}
in ConditionAndOr class. I asked a question about it in H2/issues:
https://github.com/h2database/h2database/issues/670. Waiting for a response now.
> SQL: JOIN with multiple conditions is extremely slow
>
>
> Key: IGNITE-6085
> URL: https://issues.apache.org/jira/browse/IGNITE-6085
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
> Labels: performance
> Fix For: 2.4
>
>
> Consider the following query:
> {code}
> SELECT ... FROM A a
> INNER JOIN B b ON b.id = a.foreign_id1 OR b.id = a.foreign_id2
> {code}
> In this case H2 cannot use indexes on {{foreign_id1}} or {{foreign_id2}}
> columns and query execution takes extraordinary time. Known workaround for a
> problem is to apply multiple JOINs, e.g.:
> {code}
> SELECT ... FROM A a
> LEFT OUTER JOIN B b1 ON b1.id = a.foreign_id1
> LEFT OUTER JOIN B b2 ON b2.id = a.foreign_id2
> WHERE b1.id IS NOT NULL AND b2.id IS NOT NULL
> {code}
> On a single real-world scenario it improved exeution time by a factor of 500
> (from 4s to 80ms).
> Something is terribly wrong here. Probably, H2 cannot perform necessary query
> re-write, or cannot understand how to use index. Let's find a way to fix that.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-6085) SQL: JOIN with multiple conditions is extremely slow
[
https://issues.apache.org/jira/browse/IGNITE-6085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov reassigned IGNITE-6085:
--
Assignee: Roman Kondakov
> SQL: JOIN with multiple conditions is extremely slow
>
>
> Key: IGNITE-6085
> URL: https://issues.apache.org/jira/browse/IGNITE-6085
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
> Labels: performance
> Fix For: 2.4
>
>
> Consider the following query:
> {code}
> SELECT ... FROM A a
> INNER JOIN B b ON b.id = a.foreign_id1 OR b.id = a.foreign_id2
> {code}
> In this case H2 cannot use indexes on {{foreign_id1}} or {{foreign_id2}}
> columns and query execution takes extraordinary time. Known workaround for a
> problem is to apply multiple JOINs, e.g.:
> {code}
> SELECT ... FROM A a
> LEFT OUTER JOIN B b1 ON b1.id = a.foreign_id1
> LEFT OUTER JOIN B b2 ON b2.id = a.foreign_id2
> WHERE b1.id IS NOT NULL AND b2.id IS NOT NULL
> {code}
> On a single real-world scenario it improved exeution time by a factor of 500
> (from 4s to 80ms).
> Something is terribly wrong here. Probably, H2 cannot perform necessary query
> re-write, or cannot understand how to use index. Let's find a way to fix that.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6406) SQL: CREATE INDEX should fill index from multiple threads
[
https://issues.apache.org/jira/browse/IGNITE-6406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251682#comment-16251682
]
Roman Kondakov edited comment on IGNITE-6406 at 11/14/17 4:36 PM:
--
[~vozerov], refactored after review. Tests are ok.
was (Author: rkondakov):
[~vozerov], refactored after review.
> SQL: CREATE INDEX should fill index from multiple threads
> -
>
> Key: IGNITE-6406
> URL: https://issues.apache.org/jira/browse/IGNITE-6406
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
> Labels: iep-1, performance
> Fix For: 2.4
>
>
> Currently when {{CREATE INDEX}} command is executed, we fill new index from a
> single thread. Low CPU, long create time. We can trade off CPU vs time by
> adding more threads.
> Probably number of threads should be specified in {{CREATE INDEX}} command as
> a hint.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6406) SQL: CREATE INDEX should fill index from multiple threads
[
https://issues.apache.org/jira/browse/IGNITE-6406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251682#comment-16251682
]
Roman Kondakov commented on IGNITE-6406:
[~vozerov], refactored after review.
> SQL: CREATE INDEX should fill index from multiple threads
> -
>
> Key: IGNITE-6406
> URL: https://issues.apache.org/jira/browse/IGNITE-6406
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
> Labels: iep-1, performance
> Fix For: 2.4
>
>
> Currently when {{CREATE INDEX}} command is executed, we fill new index from a
> single thread. Low CPU, long create time. We can trade off CPU vs time by
> adding more threads.
> Probably number of threads should be specified in {{CREATE INDEX}} command as
> a hint.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-6143) JDBC thin: support streams in ResultSet and PreparedStatement
[
https://issues.apache.org/jira/browse/IGNITE-6143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov reassigned IGNITE-6143:
--
Assignee: (was: Roman Kondakov)
> JDBC thin: support streams in ResultSet and PreparedStatement
> -
>
> Key: IGNITE-6143
> URL: https://issues.apache.org/jira/browse/IGNITE-6143
> Project: Ignite
> Issue Type: Task
> Components: jdbc
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>
> The most of the methods:
> - {{PreparedStatement.setXXXStream()}
> - {{ResultSet.getXXXStream}}
> must be implemented. It is the requirement of the JDBC compliance.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-6406) SQL: CREATE INDEX should fill index from multiple threads
[
https://issues.apache.org/jira/browse/IGNITE-6406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov reassigned IGNITE-6406:
--
Assignee: Roman Kondakov
> SQL: CREATE INDEX should fill index from multiple threads
> -
>
> Key: IGNITE-6406
> URL: https://issues.apache.org/jira/browse/IGNITE-6406
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
> Labels: iep-1, performance
>
> Currently when {{CREATE INDEX}} command is executed, we fill new index from a
> single thread. Low CPU, long create time. We can trade off CPU vs time by
> adding more threads.
> Probably number of threads should be specified in {{CREATE INDEX}} command as
> a hint.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6851) CREATE INDEX statement should accept no name indexes
Roman Kondakov created IGNITE-6851: -- Summary: CREATE INDEX statement should accept no name indexes Key: IGNITE-6851 URL: https://issues.apache.org/jira/browse/IGNITE-6851 Project: Ignite Issue Type: Bug Security Level: Public (Viewable by anyone) Components: sql Affects Versions: None Reporter: Roman Kondakov Ignite SqlParser failed to parse CREATE INDEX statement with missed index name. Examples: "CREATE INDEX idx_city_id on Person (city_id)" - OK "CREATE INDEX on Person (city_id)" - Fail -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6837) Create a CREATE INDEX benchmark
[ https://issues.apache.org/jira/browse/IGNITE-6837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16242356#comment-16242356 ] Roman Kondakov commented on IGNITE-6837: [~vozerov], please review the patch: [https://github.com/apache/ignite/pull/2991] > Create a CREATE INDEX benchmark > --- > > Key: IGNITE-6837 > URL: https://issues.apache.org/jira/browse/IGNITE-6837 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: yardstick >Reporter: Roman Kondakov >Assignee: Roman Kondakov > Labels: benchmark > Fix For: 2.4 > > > We need to implement a benchmark for the dynamically created indexes build > time in order to test our optimizations. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6837) Create a CREATE INDEX benchmark
[ https://issues.apache.org/jira/browse/IGNITE-6837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Kondakov updated IGNITE-6837: --- Component/s: yardstick > Create a CREATE INDEX benchmark > --- > > Key: IGNITE-6837 > URL: https://issues.apache.org/jira/browse/IGNITE-6837 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: yardstick >Reporter: Roman Kondakov >Assignee: Roman Kondakov > Labels: benchmark > Fix For: 2.4 > > > We need to implement a benchmark for the dynamically created indexes build > time in order to test our optimizations. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6837) Create a CREATE INDEX benchmark
[ https://issues.apache.org/jira/browse/IGNITE-6837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Kondakov updated IGNITE-6837: --- Fix Version/s: 2.4 > Create a CREATE INDEX benchmark > --- > > Key: IGNITE-6837 > URL: https://issues.apache.org/jira/browse/IGNITE-6837 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) >Reporter: Roman Kondakov >Assignee: Roman Kondakov > Labels: benchmark > Fix For: 2.4 > > > We need to implement a benchmark for the dynamically created indexes build > time in order to test our optimizations. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6837) Create a CREATE INDEX benchmark
Roman Kondakov created IGNITE-6837: -- Summary: Create a CREATE INDEX benchmark Key: IGNITE-6837 URL: https://issues.apache.org/jira/browse/IGNITE-6837 Project: Ignite Issue Type: Improvement Security Level: Public (Viewable by anyone) Reporter: Roman Kondakov Assignee: Roman Kondakov We need to implement a benchmark for the dynamically created indexes build time in order to test our optimizations. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6701) Do not deserialize previous value during indexes update
[ https://issues.apache.org/jira/browse/IGNITE-6701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Kondakov reassigned IGNITE-6701: -- Assignee: Roman Kondakov > Do not deserialize previous value during indexes update > --- > > Key: IGNITE-6701 > URL: https://issues.apache.org/jira/browse/IGNITE-6701 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: sql >Reporter: Semen Boikov >Assignee: Roman Kondakov > Labels: iep-1, performance > Fix For: 2.4 > > > In GridH2Table.doUpdate all indexes are updated using BPlusTree.put method > which deserializes previous value, actually previous value is already > available in GridQueryProcessor.store/remove methods. Need try to change > GridH2Table.doUpdate to use BPlusTree.putx instead of BPlusTree.put. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6141) JDBC thin: support BLOB and CLOB types
[ https://issues.apache.org/jira/browse/IGNITE-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16225235#comment-16225235 ] Roman Kondakov commented on IGNITE-6141: [~vozerov], please review. [~tledkov-gridgain] please review [test results|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests_Ignite20Tests=pull%2F2933%2Fmerge] are OK. > JDBC thin: support BLOB and CLOB types > -- > > Key: IGNITE-6141 > URL: https://issues.apache.org/jira/browse/IGNITE-6141 > Project: Ignite > Issue Type: Task > Components: jdbc >Affects Versions: 2.1 >Reporter: Taras Ledkov >Assignee: Roman Kondakov > > Support BLOB and CLOB types by JDBC thin driver. > It is very useful types. jdbc2 driver has supported one already (IGNITE-5203). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6141) JDBC thin: support BLOB and CLOB types
[ https://issues.apache.org/jira/browse/IGNITE-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16220473#comment-16220473 ] Roman Kondakov commented on IGNITE-6141: [Tests results|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests_Ignite20Tests=pull%2F2933%2Fhead] > JDBC thin: support BLOB and CLOB types > -- > > Key: IGNITE-6141 > URL: https://issues.apache.org/jira/browse/IGNITE-6141 > Project: Ignite > Issue Type: Task > Components: jdbc >Affects Versions: 2.1 >Reporter: Taras Ledkov >Assignee: Roman Kondakov > > Support BLOB and CLOB types by JDBC thin driver. > It is very useful types. jdbc2 driver has supported one already (IGNITE-5203). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6143) JDBC thin: support streams in ResultSet and PreparedStatement
[
https://issues.apache.org/jira/browse/IGNITE-6143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov reassigned IGNITE-6143:
--
Assignee: Roman Kondakov (was: Roman Shtykh)
> JDBC thin: support streams in ResultSet and PreparedStatement
> -
>
> Key: IGNITE-6143
> URL: https://issues.apache.org/jira/browse/IGNITE-6143
> Project: Ignite
> Issue Type: Task
> Components: jdbc
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>Assignee: Roman Kondakov
>
> The most of the methods:
> - {{PreparedStatement.setXXXStream()}
> - {{ResultSet.getXXXStream}}
> must be implemented. It is the requirement of the JDBC compliance.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-6141) JDBC thin: support BLOB and CLOB types
[ https://issues.apache.org/jira/browse/IGNITE-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Kondakov reassigned IGNITE-6141: -- Assignee: Roman Kondakov > JDBC thin: support BLOB and CLOB types > -- > > Key: IGNITE-6141 > URL: https://issues.apache.org/jira/browse/IGNITE-6141 > Project: Ignite > Issue Type: Task > Components: jdbc >Affects Versions: 2.1 >Reporter: Taras Ledkov >Assignee: Roman Kondakov > > Support BLOB and CLOB types by JDBC thin driver. > It is very useful types. jdbc2 driver has supported one already (IGNITE-5203). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
