[jira] [Created] (IGNITE-7973) TX SQL: plain INSERT should not be broadcasted to all data nodes
Vladimir Ozerov created IGNITE-7973: --- Summary: TX SQL: plain INSERT should not be broadcasted to all data nodes Key: IGNITE-7973 URL: https://issues.apache.org/jira/browse/IGNITE-7973 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Fix For: 2.5 At the moment all {{INSERT}} statements are broadcasted. This could be OK for {{INSERT ... SELECT}}, but is definitely not needed for {{INSERT ... VALUES}}. Instead we should construct final key-value pairs locally, and then send them to affected data nodes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7866) TcpCommunicationSpi metrics causes cache operations slowdown
Vladimir Ozerov created IGNITE-7866: --- Summary: TcpCommunicationSpi metrics causes cache operations slowdown Key: IGNITE-7866 URL: https://issues.apache.org/jira/browse/IGNITE-7866 Project: Ignite Issue Type: Task Components: general Affects Versions: 2.4 Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.4 Extended TCP metrics were added as a part of IGNITE-6868 ticket. Unfortunately, they causes ~5-10% performance drop for cache operations when working in in-memory mode. Causes: 1) Contention on shared data structures (LongAdder, CMH) 2) A lot of string comparisons because we use class names to track particulat message types Suggested fix: 1) Move all processing to NIO threads 2) Introcduce thread-local state and update it from NIO threads 3) Metrics readers should merge state from all NIO threads 4) User {{Message}} type ID instead of class names 5) When returning final result we should use {{Class.getName()}} instead of {{Class.getSimpleName()}} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9810) Potential SQL performance drop between AI 2.6 and AI 2.7
Vladimir Ozerov created IGNITE-9810: --- Summary: Potential SQL performance drop between AI 2.6 and AI 2.7 Key: IGNITE-9810 URL: https://issues.apache.org/jira/browse/IGNITE-9810 Project: Ignite Issue Type: Task Components: sql, yardstick Reporter: Vladimir Ozerov Fix For: 2.7 At the moment Yardstick benchmarks show 5-7% performance drop in several SQL benchmarks. Need to find out whether these numbers are stable, and if yes - isolate problematic commit. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9864) CacheQueriesTest test fails in .NET
Vladimir Ozerov created IGNITE-9864: --- Summary: CacheQueriesTest test fails in .NET Key: IGNITE-9864 URL: https://issues.apache.org/jira/browse/IGNITE-9864 Project: Ignite Issue Type: Task Components: platforms Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.7 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9880) Document MVCC write conflict exceptions
Vladimir Ozerov created IGNITE-9880: --- Summary: Document MVCC write conflict exceptions Key: IGNITE-9880 URL: https://issues.apache.org/jira/browse/IGNITE-9880 Project: Ignite Issue Type: Task Components: documentation Reporter: Vladimir Ozerov Assignee: Artem Budnikov Fix For: 2.7 When an entry is read (1) inside a transaction and then updated (2), there is a chance that concurrent transaction will modify that entry in between (1) and (2). In this case an error is thrown from the first transaction when action (2) is performed and transaction is marked as "rollback only". User need to re-try the whole transaction in this case. When native APi is used, then {{CacheException}} is thrown with special message {{Cannot serialize transaction due to write conflict (transaction is marked for rollback)}}. This will be changed in future (AI 2.8|) - special exception type will be thrown. When JDBC or ODBC are used, then special SQLSTATE code 40001 (aka "Serialization failure") is propagated to user. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9882) OOME in Hadoop suite
Vladimir Ozerov created IGNITE-9882: --- Summary: OOME in Hadoop suite Key: IGNITE-9882 URL: https://issues.apache.org/jira/browse/IGNITE-9882 Project: Ignite Issue Type: Task Components: hadoop, sql Reporter: Vladimir Ozerov Assignee: Taras Ledkov Fix For: 2.7 Hadoop suite starts failing with OOME after several commits were merged. I suspect that it may be related to IGNITE-9171 merge. See two runs: 1) Before: https://ci.ignite.apache.org/viewLog.html?buildId=2088527; 2) After: https://ci.ignite.apache.org/viewLog.html?buildId=2088768; -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9888) Document MVCC continuous queries
Vladimir Ozerov created IGNITE-9888: --- Summary: Document MVCC continuous queries Key: IGNITE-9888 URL: https://issues.apache.org/jira/browse/IGNITE-9888 Project: Ignite Issue Type: Task Components: documentation Reporter: Vladimir Ozerov Assignee: Artem Budnikov Fix For: 2.7 Key differences with continuous queries for non-MVCC caches: 1) When event is received, subsequent read of the same key may still return previous value for some time (i.e. no guarantee of happens-before between event and subsequent read) 2) Keys for notification are kept in memory. If transaction is too large, OOME could happen. In order to avoid that, we skip notification of too large transactions. [~rkondakov], could you please elaborate on how is this implemented? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9960) SQL: Revert and reopen lazy flag optimization (IGNITE-9171)
Vladimir Ozerov created IGNITE-9960: --- Summary: SQL: Revert and reopen lazy flag optimization (IGNITE-9171) Key: IGNITE-9960 URL: https://issues.apache.org/jira/browse/IGNITE-9960 Project: Ignite Issue Type: Task Components: sql Affects Versions: 2.7 Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.7 Benchmarks revealed very serious performance drop. We need to rollback IGNITE-9171 and IGNITE-9864 (dependent) for now. Both tickets should be reopened, performance drop should be investigated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9927) Fix flaky failures in CacheContinuousQueryOperationFromCallbackTest
Vladimir Ozerov created IGNITE-9927: --- Summary: Fix flaky failures in CacheContinuousQueryOperationFromCallbackTest Key: IGNITE-9927 URL: https://issues.apache.org/jira/browse/IGNITE-9927 Project: Ignite Issue Type: Task Components: mvcc Reporter: Vladimir Ozerov Assignee: Roman Kondakov Fix For: 2.8 This test was reworked significantly as a part of IGNITE-7953. Unfortunately it led to a number of failures appearing from time to time. The goal of this ticket is to get rid of these failures. Changes from {{51a202a4c48220fa919f47147bd4889033cd35a8}} commit should be applied to the test before starting investigation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9919) IgniteHadoopFileSystemAbstractSelfTest.testRenameIfSrcPathIsAlreadyBeingOpenedToRead fails
Vladimir Ozerov created IGNITE-9919: --- Summary: IgniteHadoopFileSystemAbstractSelfTest.testRenameIfSrcPathIsAlreadyBeingOpenedToRead fails Key: IGNITE-9919 URL: https://issues.apache.org/jira/browse/IGNITE-9919 Project: Ignite Issue Type: Task Components: hadoop Reporter: Vladimir Ozerov Reason is unknown, need to investigate. {code} java.io.IOException: Stream has been closed: IgfsOutputStreamImpl [mode=DUAL_ASYNC, writeFut=GridFutureAdapter [ignoreInterrupts=false, state=DONE, res=true, hash=237512060], fileInfo=IgfsFileInfo [len=0, blockSize=524288, lockId=afa3a228661-124a3e4e-7712-45a7-830b-8a03ac6be6a2, affKey=null, fileMap=IgfsFileMap [ranges=null], evictExclude=true], streamRange=null] {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9920) Hadoop: native dependencies are not resolved properly
Vladimir Ozerov created IGNITE-9920: --- Summary: Hadoop: native dependencies are not resolved properly Key: IGNITE-9920 URL: https://issues.apache.org/jira/browse/IGNITE-9920 Project: Ignite Issue Type: Task Components: hadoop Reporter: Vladimir Ozerov Probably caused by Hadoop version update, which was necessary for Java 9+ support. Failed tests: # HadoopSnappyTest.testSnappy # HadoopSnappyFullMapReduceTest.testWholeMapReduceExecution # HadoopTeraSortTest.testTeraSort # HadoopTeraSortTest.testTeraSortGzip # HadoopCommandLineTest.testHiveCommandLine -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10105) AI 2.7: Prepare release notes
Vladimir Ozerov created IGNITE-10105: Summary: AI 2.7: Prepare release notes Key: IGNITE-10105 URL: https://issues.apache.org/jira/browse/IGNITE-10105 Project: Ignite Issue Type: Task Components: general Reporter: Vladimir Ozerov Fix For: 2.7 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10000) Document IGNITE.CACHE_GROUPS view
Vladimir Ozerov created IGNITE-1: Summary: Document IGNITE.CACHE_GROUPS view Key: IGNITE-1 URL: https://issues.apache.org/jira/browse/IGNITE-1 Project: Ignite Issue Type: Task Components: documentation Reporter: Vladimir Ozerov Assignee: Artem Budnikov Fix For: 2.8 New SQL view was introduced in IGNITE-9780. It lists cluster cache groups. Most fields are self-descriptive, their names and data types could be found in the code [1]. [1] https://github.com/apache/ignite/blob/master/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/sys/view/SqlSystemViewCacheGroups.java -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10055) MVCC: incorrect fields count in PartitionUpdateCountersMessage
Vladimir Ozerov created IGNITE-10055: Summary: MVCC: incorrect fields count in PartitionUpdateCountersMessage Key: IGNITE-10055 URL: https://issues.apache.org/jira/browse/IGNITE-10055 Project: Ignite Issue Type: Task Components: mvcc Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.7 Should be 2. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10231) SQL: Extract partition pruning logic from splitter
Vladimir Ozerov created IGNITE-10231: Summary: SQL: Extract partition pruning logic from splitter Key: IGNITE-10231 URL: https://issues.apache.org/jira/browse/IGNITE-10231 Project: Ignite Issue Type: Task Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.8 We will need this in multiple places outside of splitter. Ideally, it should be H2-agnostic. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10294) SQL: subjectId is lost for SqlFieldsQuery event on local node
Vladimir Ozerov created IGNITE-10294: Summary: SQL: subjectId is lost for SqlFieldsQuery event on local node Key: IGNITE-10294 URL: https://issues.apache.org/jira/browse/IGNITE-10294 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.8 See {{GridQueryProcessor.sendQueryExecutedEvent}} - we pass {{null}} as subject ID. Need to fix it to local node ID. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10299) SQL: Extract SELECT and DML plan caches into single class
Vladimir Ozerov created IGNITE-10299: Summary: SQL: Extract SELECT and DML plan caches into single class Key: IGNITE-10299 URL: https://issues.apache.org/jira/browse/IGNITE-10299 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.8 In future we will need to merge plans for both DML and SELECTs (both local and distributed) into a single entity. This ticket is the first part of this effort - let's just extract both plan caches into a single class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10253) Merge SqlQuery logic with SqlFieldsQuery
Vladimir Ozerov created IGNITE-10253: Summary: Merge SqlQuery logic with SqlFieldsQuery Key: IGNITE-10253 URL: https://issues.apache.org/jira/browse/IGNITE-10253 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.8 Currently execution of {{SqlQuery}} query is very non-trivial. First, it is complex to understand. Second, it duplicates code. Third, the most important - it is buggy. Because when new logic is added to {{SqlFieldsQuery}} it is not added to {{SqlQuery}} with high probability. Moreover, we even have discrepancies between local and non-local modes. E.g. it has different value conversion logic. We need to do the following: 1) Remove all {{SqlQuery}}-specific logic from {{GridQueryProcessor}} and {{IgniteH2Indexing}} 2) Make {{SqlQuery}} work as follows: - generate {{SqlFieldsQuery}} from {{SqlQuery}} - execute it - convert results to K-V pairs -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10267) Deprecate "replicatedOnly" flag in thin clients
Vladimir Ozerov created IGNITE-10267: Summary: Deprecate "replicatedOnly" flag in thin clients Key: IGNITE-10267 URL: https://issues.apache.org/jira/browse/IGNITE-10267 Project: Ignite Issue Type: Task Components: sql, thin client Reporter: Vladimir Ozerov Fix For: 2.8 {{SqlQuery.replicatedOnly}} and {{SqlFieldsQuery.replicatedOnly}} flags were deprecated. Need to do the same for thin clients. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10268) Remove documentation about "replicatedOnly" flag
Vladimir Ozerov created IGNITE-10268: Summary: Remove documentation about "replicatedOnly" flag Key: IGNITE-10268 URL: https://issues.apache.org/jira/browse/IGNITE-10268 Project: Ignite Issue Type: Task Components: documentation Reporter: Vladimir Ozerov Assignee: Artem Budnikov Fix For: 2.8 SqlQuery.replicatedOnly and SqlFieldsQuery.replicatedOnly flags were deprecated. Need to remove all places where it is mentioned from docs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10270) MVCC: Pass transaction labels to MVCC
Vladimir Ozerov created IGNITE-10270: Summary: MVCC: Pass transaction labels to MVCC Key: IGNITE-10270 URL: https://issues.apache.org/jira/browse/IGNITE-10270 Project: Ignite Issue Type: Task Components: mvcc Reporter: Vladimir Ozerov Fix For: 2.8 Transaction labels were introduced in IGNITE-9274. Need to pass them to MVCC messages as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10269) MVCC: CacheMvccReplicatedBackupsTest fails when query over REPLICATED cache is converted to local form
Vladimir Ozerov created IGNITE-10269: Summary: MVCC: CacheMvccReplicatedBackupsTest fails when query over REPLICATED cache is converted to local form Key: IGNITE-10269 URL: https://issues.apache.org/jira/browse/IGNITE-10269 Project: Ignite Issue Type: Task Components: mvcc, sql Reporter: Vladimir Ozerov Fix For: 2.8 Steps to reproduce: 1) Remove MVCC check from {{GridSqlQueryParser.isLocalQuery}} 2) Run {{CacheMvccReplicatedBackupsTest}} Need to investigate why test fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10271) Document transaction labels
Vladimir Ozerov created IGNITE-10271: Summary: Document transaction labels Key: IGNITE-10271 URL: https://issues.apache.org/jira/browse/IGNITE-10271 Project: Ignite Issue Type: Task Components: documentation Reporter: Vladimir Ozerov Assignee: Artem Budnikov Added in IGNITE-9274. Label can be defined for transaction, which is then passed to cache events. Needed for monitoring. Usage: {code} try (Transaction tx = node.transactions().withLabel("myLabel").txStart()) { ... } {code} When label is passed this way, it will be reflected in {{CacheEvent.txLabel()}} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9786) MVCC: simplify TX wait list management
Vladimir Ozerov created IGNITE-9786: --- Summary: MVCC: simplify TX wait list management Key: IGNITE-9786 URL: https://issues.apache.org/jira/browse/IGNITE-9786 Project: Ignite Issue Type: Task Components: mvcc Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.8 It seems that instead of having a lot of classes and complex synchronization mechanics for MvccProcessorImpl.waitMap, we can use single wrapper with a list of waiters. Resulting code will be much more simpler and less prone to concurrency issues. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9819) SQL: document recomendation to use TIMESTAMP instead of DATE
Vladimir Ozerov created IGNITE-9819: --- Summary: SQL: document recomendation to use TIMESTAMP instead of DATE Key: IGNITE-9819 URL: https://issues.apache.org/jira/browse/IGNITE-9819 Project: Ignite Issue Type: Task Components: documentation Reporter: Vladimir Ozerov Assignee: Artem Budnikov Fix For: 2.7 We support both DATE (date only) and TIMESTAMP (date + time) data types. Unfortunately, DATE data type is serialized/deserialized very inefficiently, what leads to performance degradation. We need to warn users in documentation, that it is better to use TIMESTAMP than DATE. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9831) Document how to work with Java 11
Vladimir Ozerov created IGNITE-9831: --- Summary: Document how to work with Java 11 Key: IGNITE-9831 URL: https://issues.apache.org/jira/browse/IGNITE-9831 Project: Ignite Issue Type: Task Components: documentation Reporter: Vladimir Ozerov Fix For: 2.7 TBD -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9835) Document IGNITE.CACHES system view
Vladimir Ozerov created IGNITE-9835: --- Summary: Document IGNITE.CACHES system view Key: IGNITE-9835 URL: https://issues.apache.org/jira/browse/IGNITE-9835 Project: Ignite Issue Type: Task Components: documentation Reporter: Vladimir Ozerov Assignee: Artem Budnikov Fix For: 2.8 New system view has been added to the product - IGNITE.CACHES. Please see it's columns in the source code [1], which is pretty self-descriptive. Most of them are taken from cache configuration. [1] https://github.com/apache/ignite/blob/master/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/sys/view/SqlSystemViewCaches.java -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9435) Document MVCC
Vladimir Ozerov created IGNITE-9435: --- Summary: Document MVCC Key: IGNITE-9435 URL: https://issues.apache.org/jira/browse/IGNITE-9435 Project: Ignite Issue Type: Task Components: documentation, mvcc Reporter: Vladimir Ozerov Fix For: 2.7 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9704) JDBC thin: round-robin connection distribution
Vladimir Ozerov created IGNITE-9704: --- Summary: JDBC thin: round-robin connection distribution Key: IGNITE-9704 URL: https://issues.apache.org/jira/browse/IGNITE-9704 Project: Ignite Issue Type: Task Components: jdbc Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.7 Currently every connection picks random IP address from connection string. This may lead to considerable imbalances between cluster nodes. Let's user round-robin instead of random. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9703) JDBC thick: do no throw exception from setReadOnly method
Vladimir Ozerov created IGNITE-9703: --- Summary: JDBC thick: do no throw exception from setReadOnly method Key: IGNITE-9703 URL: https://issues.apache.org/jira/browse/IGNITE-9703 Project: Ignite Issue Type: Task Components: jdbc Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.7 This method is harmless and might be called from various {{DataSource}} implementations. E.g. connection pools such as Hikary. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9696) SQL: Remove documentation about bad IN performance
Vladimir Ozerov created IGNITE-9696: --- Summary: SQL: Remove documentation about bad IN performance Key: IGNITE-9696 URL: https://issues.apache.org/jira/browse/IGNITE-9696 Project: Ignite Issue Type: Task Components: documentation Reporter: Vladimir Ozerov Assignee: Artem Budnikov Fix For: 2.7 As IGNITE-4150 is merged, we should no longer have problems with IN statement. Let's remove it. See [https://apacheignite-sql.readme.io/docs/performance-and-debugging#sql-performance-and-usability-considerations] , point 2. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9714) Document ODBC streaming mode
Vladimir Ozerov created IGNITE-9714: --- Summary: Document ODBC streaming mode Key: IGNITE-9714 URL: https://issues.apache.org/jira/browse/IGNITE-9714 Project: Ignite Issue Type: Task Components: documentation Reporter: Artem Budnikov Fix For: 2.7 Need to document ODBC streaming mode introduced in IGNITE-7855. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10311) SQL: Create system view with query co-location plans
Vladimir Ozerov created IGNITE-10311: Summary: SQL: Create system view with query co-location plans Key: IGNITE-10311 URL: https://issues.apache.org/jira/browse/IGNITE-10311 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Fix For: 2.8 It is very important to understand model of distributed execution for certain queries for performance tuning. Let's create a syhstem view which will iterate over cached two-step queries and print their plans in table form. Approximate structure (very raw): {code} CREATE VIEW sql_query_plan ( plan_id, // Unique plan ID (node ID + unique local ID) sql, // Plain text sql_hash. // May be more convenient that query_id flags // Same query with different flags may result in different plans ) CREATE VIEW sql_query_plan_fragments ( plan_id, // Same plan ID order, // Together with plan_id it forms PK action, // What is this - "reduce", "skip reduce", "map", etc. (may be we will need multiple columns) sql, // SQL of the fragment (if applicable) ) {code} Next user may list cached plans, select interesting, and query plan fragments view. We need to analyze other vendors to better understand what to show in views. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10304) SQL: Encapsulate H2 query execution into ConnectionManager
Vladimir Ozerov created IGNITE-10304: Summary: SQL: Encapsulate H2 query execution into ConnectionManager Key: IGNITE-10304 URL: https://issues.apache.org/jira/browse/IGNITE-10304 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Fix For: 2.8 This ticket should be done after IGNITE-10299. Currently {{ConnectionManager}} exposes cached H2 connections to the outside. Sometimes these connections are used in safe manner and {{ConnectionManager.onSqlException}} is called to recycle bad connection. But most of the time this is not the case, what may lead to unexpected behavior. Let's try to hide all statement execution logic inside {{ConnectionManager}} to avoid this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10306) SQL: Transform subqueries to JOINs when possible
Vladimir Ozerov created IGNITE-10306: Summary: SQL: Transform subqueries to JOINs when possible Key: IGNITE-10306 URL: https://issues.apache.org/jira/browse/IGNITE-10306 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Fix For: 2.8 Currently subqueries are mostly not analyzed in any way. This makes our distributed execution plan more complex to analyze and execute. Moreover, we cannot extract partition information from such queries efficiently. We need to apply the simplest "JOIN conversion" optimization on early query analysis phase and try to transform our AST from subquery to join. This should be done before partition extraction, pushdowns and splitter. See [1] for more information. [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-24%3A+SQL+Partition+Pruning -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10303) SQL: Move connection management logic into separate class
Vladimir Ozerov created IGNITE-10303: Summary: SQL: Move connection management logic into separate class Key: IGNITE-10303 URL: https://issues.apache.org/jira/browse/IGNITE-10303 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.8 Currently {{IgniteH2Indexing}} class is a mix of various mixed abstractions. One of them is connection management. Let's abstract it out. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10310) SQL: Create TABLEs system view with affinity information
Vladimir Ozerov created IGNITE-10310: Summary: SQL: Create TABLEs system view with affinity information Key: IGNITE-10310 URL: https://issues.apache.org/jira/browse/IGNITE-10310 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Fix For: 2.8 Lets add a system view with our tables. At the very least it should include: # table name # cache name # schema name # affinity column # affinity key (if IGNITE-10309 is implemented) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10309) SQL: Ability to specifiy affinity function equality during table creation
Vladimir Ozerov created IGNITE-10309: Summary: SQL: Ability to specifiy affinity function equality during table creation Key: IGNITE-10309 URL: https://issues.apache.org/jira/browse/IGNITE-10309 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Fix For: 2.8 Currently users may specify affinity key in {{CREATE TABLE}} command. However, there are situations when custom affintiy function or custom affinity mapper are used. In this case we do not know what actual fields are used for affinity calculation, neither we know if two affinity functions are equal and produce deterministic results *. In this case we may want to give user ability to confirm on his own risk that certain caches has the same affinity functions and are co-located. To achieve this all we need is to add new string parameter, say, {{AFFINITY_FUNCTION_KEY}}. Then, if we meet caches with unknown affinity function, we may compare their affinity functions keys. If they match, then we may treat them co-located and extract partitions successfully. * Remember our {{RendezvousAffinityFunction}} which is stateless, and old {{FairAffinityFunction}} which depend on cluster history and may produce different distributions between two caches even if two caches has the same function parameters. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10305) SQL: Optimize query execution if it targets only one or none partitions
Vladimir Ozerov created IGNITE-10305: Summary: SQL: Optimize query execution if it targets only one or none partitions Key: IGNITE-10305 URL: https://issues.apache.org/jira/browse/IGNITE-10305 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Fix For: 2.8 This is a part of "Partition Pruning" IEP [1]. Currently we try to extract partitions from map queries and route requests accordingly. Several problems with this approach: 1) Individual map queries may target the same partition, but we never know that, so we may want to setup a merge table when it is not really needed. 2) Sometimes query may reduce to no partitions. In this case we should not execute anything at all and simply return empty result set. 3) If the whole query targets only one partition, we may skip the whole splitter phase! I propose to do the following: # Try to extract partition from "original" query. # If we see that exactly one partition is involved, then original query is a map query, and reduce should be performed in "skip merge table" mode # If we see that there are no partitions because query is invalid (e.g. {{id = 1 AND id = 2}}), then stop and return no results. This decision should be cached in two-step plan. # If we see that there are some partitions, then we should apply arguments and see the result. If result set is empty - return, but do not cache empty result set decision, as it may change for another set of arguments. # If none of above hold, then do pushdowns and split, and analyze partitions of individual map queries. For those of them where partition set is empty, we should return empty result set without executing anything. [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-24%3A+SQL+Partition+Pruning -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10307) SQL: Extract partition info from JOINs
Vladimir Ozerov created IGNITE-10307: Summary: SQL: Extract partition info from JOINs Key: IGNITE-10307 URL: https://issues.apache.org/jira/browse/IGNITE-10307 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Fix For: 2.8 Currently we do not extract partitions when JOINs are involved. Let's implement it. We may start with relatively simple rules: # No subqueries # No GROUP BY Then walk through JOINed tables and extract partitions from AND clauses. There are some tricky things to consider: # Resulting model (tree) must be craefted carefully so that we can reuse it later in thin clients for efficient co-location. # Resulting model may affect how we group tables during push-down phase. Probably this would be huuuge thing, so may be it is better to implement it in separate ticket # When JOIN is performed partition info might be "transferred" between tables. E.g.: {code} a INNER JOIN b ON a.id = b.affinity_id WHERE a.id = :1 {code} In this case if tables are co-located (we may infer it automatically in some cases), then {{a.id=:1}} partition rule can be "transferred" to {{b.affinity_id=:1}}. Very good test coverage would be needed here. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10308) SQL: Pass partition pruning models to JDBC thin driver
Vladimir Ozerov created IGNITE-10308: Summary: SQL: Pass partition pruning models to JDBC thin driver Key: IGNITE-10308 URL: https://issues.apache.org/jira/browse/IGNITE-10308 Project: Ignite Issue Type: Task Components: jdbc, sql Reporter: Vladimir Ozerov Fix For: 2.8 Once partitions are extracted from original query (IGNITE-10305), it might be useful for thin clients: they could apply arguments locally and try to guess the best node where to send the request. Example: when there is only one partition, then it makes sense to send the request directly to that node, so that only one hop is needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10985) SQL: create low-overhead implementation of Row for SELECTs
Vladimir Ozerov created IGNITE-10985: Summary: SQL: create low-overhead implementation of Row for SELECTs Key: IGNITE-10985 URL: https://issues.apache.org/jira/browse/IGNITE-10985 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Alexander Lapin Fix For: 2.8 Currently we use {{GridH2KeyValueRowOnheap}} for both update and search operations. This leads to *huge* memory overhead during {{SELECT}} execution. If you take a closer look on what is inside the row, you will note the following: # It has both serialized and deserialized {{GridCacheVersion}} which is never needed # It has wrapped key and value object # It has reference to {{CacheDataRow}} which is not needed either # It has {{valCache}} field which is never used in SELECT The goal of this ticket is to created optimized version of row which will be created during {{SELECT}} operations only. It should contain only minimally necessary information: # Key (unwrapped!) # Value (unwrapped!) # Version (unwrapped, we will remove it completely in separate ticket) It should not contain reference to {{CacheDataRow}}. There is a chance that we will need some pieces from it (e.g. cache ID and link for caching purposes), but it definitely will be only small subset of the whole {{CacheDataRowAdapter}} (or even worse - {{MvccDataRow}}). Entry point: {{H2Tree.createRowFromLink}} methods. Note that they return {{GridH2Row}}, while in their usages only very relaxed version of {{GridH2SearchRow}} is needed. So let's start with new implementation of row for these methods and then gradually remove all unnecessary stuff from there. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10986) SQL: Drop _VER field support
Vladimir Ozerov created IGNITE-10986: Summary: SQL: Drop _VER field support Key: IGNITE-10986 URL: https://issues.apache.org/jira/browse/IGNITE-10986 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Alexander Lapin Fix For: 2.8 {{_VER}} is undocumented hidden field which is never used in practice. But profiling shows that it consumes a lot of memory. Let's drop support of this field from all {{GridH2SearchRow}} implementations, as well as from internal descriptors. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10971) SQL: Support partition pruning for distributed joins
Vladimir Ozerov created IGNITE-10971: Summary: SQL: Support partition pruning for distributed joins Key: IGNITE-10971 URL: https://issues.apache.org/jira/browse/IGNITE-10971 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Fix For: 2.8 During IGNITE-10307 implementation it was revealed that distributed joins do not work with partition pruning. We never observed it before because it was impossible to derive partitions from joins. The problem appears as timeout exception from reducer due to some timeouts/retries inside distributed joins logic. Failures could be reproduced as follows: 1) Remove {{GridSqlQuerySplitter.distributedJoins}} usage which prevents partition to be derived for map query. 2) Run any of the following tests and observe that some of tests cases fails with reducer timeout: {{IgniteSqlSplitterSelfTest}} {{IgniteCacheJoinQueryWithAffinityKeyTest}} {{IgniteCacheDistributedJoinQueryConditionsTest}} {{IgniteCacheCrossCacheJoinRandomTest}} Root cause is unknown, but most likely this is due some missing messages, because some parts of distributed join engine is not aware of extracted partitions and await for replies from not involved nodes. Note that most likely the same problem will appear for queries with distributed joins and explicit partitions ({{SqlFieldsQuery.partitions}}). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11042) Document new SQL system view "TABLES"
Vladimir Ozerov created IGNITE-11042: Summary: Document new SQL system view "TABLES" Key: IGNITE-11042 URL: https://issues.apache.org/jira/browse/IGNITE-11042 Project: Ignite Issue Type: Task Components: documentation, sql Reporter: Vladimir Ozerov Fix For: 2.8 See {{modules\indexing\src\main\java\org\apache\ignite\internal\processors\query\h2\sys\view\SqlSystemViewTables.java}} for the list of columns. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10676) Binary: optionally do not check types in metadata
Vladimir Ozerov created IGNITE-10676: Summary: Binary: optionally do not check types in metadata Key: IGNITE-10676 URL: https://issues.apache.org/jira/browse/IGNITE-10676 Project: Ignite Issue Type: Task Components: binary Reporter: Vladimir Ozerov Consider a situation when user want to re-create a table with different type for some columns. Currently it is not possible due to strict metadata checks. To fix this we may optionally skip metadata checks for certain data types. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10784) SQL: Create a view with list of existing tables
Vladimir Ozerov created IGNITE-10784: Summary: SQL: Create a view with list of existing tables Key: IGNITE-10784 URL: https://issues.apache.org/jira/browse/IGNITE-10784 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Pavel Kuznetsov Fix For: 2.8 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10783) SQL: Ability to optionally disable partition pruning
Vladimir Ozerov created IGNITE-10783: Summary: SQL: Ability to optionally disable partition pruning Key: IGNITE-10783 URL: https://issues.apache.org/jira/browse/IGNITE-10783 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Fix For: 2.8 Partition pruning is important optimization for SQL queries. But in case partitions are calculated incorrectly, it may lead to query returning less data than expected. Possibility of such scenarios should be mitigated by excessive testing. But it will not give us bug-free guarantee. Let's add special flag which will disable partition pruning for specific user queries. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10812) SQL: split classes responsible for distributed joins
Vladimir Ozerov created IGNITE-10812: Summary: SQL: split classes responsible for distributed joins Key: IGNITE-10812 URL: https://issues.apache.org/jira/browse/IGNITE-10812 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.8 This is just a refactoring task to create more precise hierarchy of classes responsible for distributed joins. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10656) SQL: Multiple columns could be used for partition pruning
Vladimir Ozerov created IGNITE-10656: Summary: SQL: Multiple columns could be used for partition pruning Key: IGNITE-10656 URL: https://issues.apache.org/jira/browse/IGNITE-10656 Project: Ignite Issue Type: Task Reporter: Vladimir Ozerov Fix For: 2.8 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10643) GridCacheContextInfo should not use isCacheContextInited() method to calculate constant properties
Vladimir Ozerov created IGNITE-10643: Summary: GridCacheContextInfo should not use isCacheContextInited() method to calculate constant properties Key: IGNITE-10643 URL: https://issues.apache.org/jira/browse/IGNITE-10643 Project: Ignite Issue Type: Task Reporter: Vladimir Ozerov Assignee: Yury Gerzhedovich Fix For: 2.8 This appears to be a regression from IGNITE-6173. Current method {{isCacheContextInited}} is used to determine several properties (config, name, customAffinityMapper, groupId, cacheId, affinityNode). This is wrong, as all of these properties are "constant" and can be deduced form configuration. One specific case when it breaks Ignite is {{customAffinityMapper}}. It is used to determine affinity key field in {{GridH2Table}} which will be used later on for partition pruning. However, when table is created on a client node and context is not initialized yet, it will return "false", and incorrect affinity key will be calculated in {{QueryUtils.typeForQueryEntity}} and in {{GridH2Table}} later on. Finally, when query is executed, incorrect partition might be derived from it leading to incorrect query result. Solution: make all mentioned methods independent of cache state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10535) SQL: extract partition mapping logic from GridReduceQueryExecutor into a separate class
Vladimir Ozerov created IGNITE-10535: Summary: SQL: extract partition mapping logic from GridReduceQueryExecutor into a separate class Key: IGNITE-10535 URL: https://issues.apache.org/jira/browse/IGNITE-10535 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.8 Goal: to simplify future code support. About 25% of {{GridReduceQueryExecutor}} code base is partition mapping ({{nodesForPartitions}}). Let's move it to a separate class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10566) SQL: Map query should operate on it's own list of partitions
Vladimir Ozerov created IGNITE-10566: Summary: SQL: Map query should operate on it's own list of partitions Key: IGNITE-10566 URL: https://issues.apache.org/jira/browse/IGNITE-10566 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Currently we merge extracted partitions from multiple map queries using {{OR}} semantics. The this list is used for execution of all queries. That is, consider that user's query was split into two map queries {{A}} and {{B}} with target partitions {{1}} and {{2}} respectively. Instead of executing {{A -> 1}} and {{B- > 2}} we will execute {{A -> 1, 2}} and {{B -> 1, 2}}, what leads to waste of resources. See {{GridH2QueryRequest#qryParts}} as a starting point. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10578) SQL: extract schema operations from IgniteH2Indexing into a separate class
Vladimir Ozerov created IGNITE-10578: Summary: SQL: extract schema operations from IgniteH2Indexing into a separate class Key: IGNITE-10578 URL: https://issues.apache.org/jira/browse/IGNITE-10578 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.8 Same reasoning as with other indexing refactoring tickets (e.g. IGNITE-10535): decouple unrelated components to simplify further development. At this point {{IgniteH2Indexing}} is critically overwhelmed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10487) SQL: Make sure that partition pruning is integrated with DML properly
Vladimir Ozerov created IGNITE-10487: Summary: SQL: Make sure that partition pruning is integrated with DML properly Key: IGNITE-10487 URL: https://issues.apache.org/jira/browse/IGNITE-10487 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Fix For: 2.8 DML re-use query execution logic for UPDATE and DELETE statements. Need to make sure that provided partition information is used properly in those queries for standard and MVCC modes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10379) SQL: Extract partition info from BETWEEN and range conditions for integer types
Vladimir Ozerov created IGNITE-10379: Summary: SQL: Extract partition info from BETWEEN and range conditions for integer types Key: IGNITE-10379 URL: https://issues.apache.org/jira/browse/IGNITE-10379 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov If there is a range condition on affinity column of integer type, we may try to extract partition info from it in a way similar to IN clause [1]: {{x BETWEEN 1 and 5}} -> {{x IN (1, 2, 3, 4, 5)}} {{x > 1 and x <= 5}} -> {{x IN (2, 3, 4, 5)}} [1] IGNITE-9632 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10329) Create JDBC "query" and "query join" benchmarks and compare them with Postgres and MySQL
Vladimir Ozerov created IGNITE-10329: Summary: Create JDBC "query" and "query join" benchmarks and compare them with Postgres and MySQL Key: IGNITE-10329 URL: https://issues.apache.org/jira/browse/IGNITE-10329 Project: Ignite Issue Type: Task Components: sql, yardstick Reporter: Vladimir Ozerov Assignee: Pavel Kuznetsov Fix For: 2.8 Currently we have {{IgniteSqlQueryBenchmark}} and {{IgniteSqlQueryJoinBenchmark}} benchmarks which query data over salary range and optionally joins it with second table. Let's create a set of similar benchmarks which will use JDBC to load and query data, and execute them against one-node Ignite cluster, MySQL and Postgres. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9570) Fix failures in CacheMvccSelectForUpdateQueryAbstractTest
Vladimir Ozerov created IGNITE-9570: --- Summary: Fix failures in CacheMvccSelectForUpdateQueryAbstractTest Key: IGNITE-9570 URL: https://issues.apache.org/jira/browse/IGNITE-9570 Project: Ignite Issue Type: Task Components: mvcc Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.7 Caused by badly formed test itself. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11630) Document changes to SQL views
Vladimir Ozerov created IGNITE-11630: Summary: Document changes to SQL views Key: IGNITE-11630 URL: https://issues.apache.org/jira/browse/IGNITE-11630 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Artem Budnikov Fix For: 2.8 The following changes were made to our views. {{CACHE_GROUPS}} # {{ID}} -> {{CACHE_GROUP_ID}} # {{GROUP_NAME}} -> {{CACHE_GROUP_NAME}} {{LOCAL_CACHE_GROUPS_IO}} # {{GROUP_ID}} -> {{CACHE_GROUP_ID}} # {{GROUP_NAME}} -> {{CACHE_GROUP_NAME}} {{CACHES}} # {{NAME}} -> {{CACHE_NAME}} # {{GROUP_ID}} -> {{CACHE_GROUP_ID}} # {{GROUP_NAME}} -> {{CACHE_GROUP_NAME}} {{INDEXES}} # {{GROUP_ID}} -> {{CACHE_GROUP_ID}} # {{GROUP_NAME}} -> {{CACHE_GROUP_NAME}} {{NODES}} # {{ID}} -> {{NODE_ID}} {{TABLES}} # Added {{CACHE_GROUP_ID}} # Added {{CACHE_GROUP_NAME}} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11648) Document SCHEMAS system view
Vladimir Ozerov created IGNITE-11648: Summary: Document SCHEMAS system view Key: IGNITE-11648 URL: https://issues.apache.org/jira/browse/IGNITE-11648 Project: Ignite Issue Type: Task Components: documentation Reporter: Vladimir Ozerov Assignee: Artem Budnikov Fix For: 2.8 We added "SCHEMAS" system view. It contains only one attribute - "SCHEMA_NAME". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11418) Document SQL IGNITE.INDEXES view
Vladimir Ozerov created IGNITE-11418: Summary: Document SQL IGNITE.INDEXES view Key: IGNITE-11418 URL: https://issues.apache.org/jira/browse/IGNITE-11418 Project: Ignite Issue Type: Task Components: documentation Reporter: Vladimir Ozerov Assignee: Artem Budnikov New {{IGNITE.INDEXES}} view was added, which displays indexes in specific columns. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11422) Remove H2 console from documentation
Vladimir Ozerov created IGNITE-11422: Summary: Remove H2 console from documentation Key: IGNITE-11422 URL: https://issues.apache.org/jira/browse/IGNITE-11422 Project: Ignite Issue Type: Task Components: documentation Reporter: Vladimir Ozerov Assignee: Artem Budnikov H2 console was deprecated as a part of IGNITE-11333. Need to remove all mentions of "H2 console" from documentation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11402) SQL: Add ability to specift inline size of PK and affinity key indexes from CREATE TABLE and QueryEntity
Vladimir Ozerov created IGNITE-11402: Summary: SQL: Add ability to specift inline size of PK and affinity key indexes from CREATE TABLE and QueryEntity Key: IGNITE-11402 URL: https://issues.apache.org/jira/browse/IGNITE-11402 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Fix For: 2.8 Currently it is not possible to set inline size for automatically created indexes easily. We need to make sure that use has convenient way to set them both programmatically and from DDL. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11404) Document CREATE TABLE "parallelism" option
Vladimir Ozerov created IGNITE-11404: Summary: Document CREATE TABLE "parallelism" option Key: IGNITE-11404 URL: https://issues.apache.org/jira/browse/IGNITE-11404 Project: Ignite Issue Type: Task Components: documentation, sql Reporter: Vladimir Ozerov Assignee: Artem Budnikov Fix For: 2.8 We added new {{PARALLELISM}} option: {code} CREATE TABLE ... WITH "parallelism = 4" {code} This option affect query parallelism which is otherwise set from {{CacheConfiguration.queryParallelism}}. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11513) MVCC: make sure that unsupported features are documented properly
Vladimir Ozerov created IGNITE-11513: Summary: MVCC: make sure that unsupported features are documented properly Key: IGNITE-11513 URL: https://issues.apache.org/jira/browse/IGNITE-11513 Project: Ignite Issue Type: Task Components: documentation Reporter: Vladimir Ozerov Fix For: 2.8 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11517) MVCC: Support one-phase commit
Vladimir Ozerov created IGNITE-11517: Summary: MVCC: Support one-phase commit Key: IGNITE-11517 URL: https://issues.apache.org/jira/browse/IGNITE-11517 Project: Ignite Issue Type: Task Components: mvcc Reporter: Vladimir Ozerov One-phase commit is critical performance optimization for single-key requests. Our profiling revealed that this is one of the key things why MVCC is much slower than non-MVCC caches. Let's add 1PC support to MVCC. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11515) MVCC: Make sure that multiple cursors are handled properly for JDBC/ODBC
Vladimir Ozerov created IGNITE-11515: Summary: MVCC: Make sure that multiple cursors are handled properly for JDBC/ODBC Key: IGNITE-11515 URL: https://issues.apache.org/jira/browse/IGNITE-11515 Project: Ignite Issue Type: Bug Components: jdbc, mvcc, odbc Reporter: Vladimir Ozerov Consider the following scenario executed from JDBC/ODBC driver: 1) Open transaction 2) Get a cursor for some large SELECT 3) Close transaction 4) Overwrite some of not-yet-returned values for the cursor 5) Force vacuum 6) Read remaining values from the cursor Will we get correct result? Most probably no, because we close transaction on commit without consulting to any opened cursors. Possible solutions: 1) Extend transaction lifetime until all cursors are closed 2) Or close the cursors forcibly and throw proper error message -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11516) MVCC management and monitoring
Vladimir Ozerov created IGNITE-11516: Summary: MVCC management and monitoring Key: IGNITE-11516 URL: https://issues.apache.org/jira/browse/IGNITE-11516 Project: Ignite Issue Type: Task Components: mvcc Reporter: Vladimir Ozerov This is an umbrella ticket for MVCC management and monitoring capabilities. This should include (but not limited to): # Proper cache metrics (standard cache operations, number of stale versions aka "bloat", etc) # MVCC coordinator metrics (node ID, number of received requests, number of active TXes, current cleanup version, current version, etc) # Cache events (either standard JCache or something else) # Deadlock detector metrics -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11518) SQL: Security checks are skipped on some SELECT paths
Vladimir Ozerov created IGNITE-11518: Summary: SQL: Security checks are skipped on some SELECT paths Key: IGNITE-11518 URL: https://issues.apache.org/jira/browse/IGNITE-11518 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.8 This is regression introduced by IGNITE-11227. Security check should be moved from {{executeSelectLocal}} to {{executeSelect0}}. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11514) MVCC: Client listener: do not delegate implicit operation execution to separate thread for JDBC/ODBC
Vladimir Ozerov created IGNITE-11514: Summary: MVCC: Client listener: do not delegate implicit operation execution to separate thread for JDBC/ODBC Key: IGNITE-11514 URL: https://issues.apache.org/jira/browse/IGNITE-11514 Project: Ignite Issue Type: Task Components: jdbc, mvcc, odbc Reporter: Vladimir Ozerov If implicit operation over MVCC cache(s) is executed from JDBC/ODBC driver, we always delegate it to a separate thread. But there is no need to do this - once we understand that no active transaction will be left after execution, query could be executed from normal listener thread safely. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11499) SQL: DML should not use batches by default
Vladimir Ozerov created IGNITE-11499: Summary: SQL: DML should not use batches by default Key: IGNITE-11499 URL: https://issues.apache.org/jira/browse/IGNITE-11499 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Fix For: 2.8 Currently DML apply updates in batches equal to {{SqlFieldsQuery.pageSize}}. This is prone to deadlocks. Instead, we should apply updates one-by-one by default. Proposal: # Introduce {{SqlFieldsQuery.updateBatchSize}} property, set it to {{1}} by default # Print a warning about deadlock to log if it is greater than 1 # Add it to JDBC and ODBC drivers -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11498) SQL: Rework DML data distribution logic
Vladimir Ozerov created IGNITE-11498: Summary: SQL: Rework DML data distribution logic Key: IGNITE-11498 URL: https://issues.apache.org/jira/browse/IGNITE-11498 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Fix For: 2.8 Current DML implementation has a number of problems: 1) We fetch the whole data set to originator's node. There is "skipDmlOnReducer" flag to avoid this in some cases, but it is still in experimental state, and is not enabled by default 2) Updates are deadlock-prone: we update entries in batches equal to {{SqlFieldsQuery.pageSize}}. So we can deadlock easily with concurrent cache operations 3) We have very strange re-try logic. It is not clear why it is needed in the first place provided that DML is not transactional and no guarantees are needed. Proposal: # Implement proper routing logic: if a request could be executed on data nodes bypassing skipping reducer, do this. Otherwise fetch all data to reducer. This decision should be made in absolutely the same way as for MVCC (see {{GridNearTxQueryEnlistFuture}} as a starting point) # Distribute updates to primary data node in batches, but apply them one by one, similar to data streamer with {{allowOverwrite=false}}. Do not do any partition state or {{AffinityTopologyVersion}} checks, since DML is not transactional. Return and aggregate update counts back. # Remove or at least rethink retry logic. Why do we need it in the first place? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11564) SQL: Implement KILL QUERY command
Vladimir Ozerov created IGNITE-11564: Summary: SQL: Implement KILL QUERY command Key: IGNITE-11564 URL: https://issues.apache.org/jira/browse/IGNITE-11564 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Fix For: 2.8 This is an umbrella ticket for {{KILL QUERY}} command implementation. Original description could be found in IGNITE-10161. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11551) SQL: Document LOCAL_SQL_QUERY_HISTORY
Vladimir Ozerov created IGNITE-11551: Summary: SQL: Document LOCAL_SQL_QUERY_HISTORY Key: IGNITE-11551 URL: https://issues.apache.org/jira/browse/IGNITE-11551 Project: Ignite Issue Type: Task Reporter: Vladimir Ozerov Name: {{LOCAL_SQL_QUERY_HISTORY}} Fields: # {{SCHEMA_NAME}} - schema name # {{SQL}} - actual SQL being executed # {{LOCAL}} - whether query was stared with "local=true" flag # {{EXECUTIONS}} - total number of executions # {{FAILURES}} - number of executions which failed # {{DURATION_MIN}} - minimum duration # {{DURATION_MAX}} - maximum duration # {{LAST_START_TIME}} - start time of the last executed query -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11510) SQL: Rework running queries tests to make them stable to internal code changes
Vladimir Ozerov created IGNITE-11510: Summary: SQL: Rework running queries tests to make them stable to internal code changes Key: IGNITE-11510 URL: https://issues.apache.org/jira/browse/IGNITE-11510 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov See {{RunningQueriesTest}}. It hacks into {{IgniteH2Indexing.querySqlFields}}. This is not resilent to internal code changes. We need to make sure that the whole test use as less hacks as possible. E.g. we can hack into running queries manager instead of indexing. Several DML tests are muted due to changes introduced in IGNITE-11227. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11511) SQL: Possible bug with parameters passing for complex DML queries
Vladimir Ozerov created IGNITE-11511: Summary: SQL: Possible bug with parameters passing for complex DML queries Key: IGNITE-11511 URL: https://issues.apache.org/jira/browse/IGNITE-11511 Project: Ignite Issue Type: Bug Components: sql Reporter: Vladimir Ozerov Assignee: Pavel Kuznetsov Fix For: 2.8 See methods {{IgniteH2Indexing.executeSelectLocal}} and {{IgniteH2Indexing.executeSelectForDml}}. They both could be invoked for {{SELECT}} statements extracted from DML. But notice how parameters are passed: it seems that we may pass parameters from DML statement unchanged, which is illegal. E.g. consider the following DML: {code} UPDATE table SET x=? WHERE x=? {code} In this case SELECT statement should get only the second parameter. Need to create tests to confirm that this is the case and make necessary fixes if needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11231) SQL: Remove scan index for merge table
Vladimir Ozerov created IGNITE-11231: Summary: SQL: Remove scan index for merge table Key: IGNITE-11231 URL: https://issues.apache.org/jira/browse/IGNITE-11231 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.8 Reasoning: # No business logic comparing to it's parent # Duplicated code for cost calculation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11340) SQL: Add OOME tests to separate suite
Vladimir Ozerov created IGNITE-11340: Summary: SQL: Add OOME tests to separate suite Key: IGNITE-11340 URL: https://issues.apache.org/jira/browse/IGNITE-11340 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Taras Ledkov Fix For: 2.8 {{IgniteQueryOOMTestSuite}} was added as a part of IGNITE-9171. We need to add this suite to TC and make sure it is executed on regular basis. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11341) SQL: Enable lazy mode by default
Vladimir Ozerov created IGNITE-11341: Summary: SQL: Enable lazy mode by default Key: IGNITE-11341 URL: https://issues.apache.org/jira/browse/IGNITE-11341 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Taras Ledkov We redesigned lazy mode, so that now it doesn't spawn new thread and has the same performance as old "eager" mode (IGNITE-9171). However, we didn't enable it by default because H2 1.4.197 contains several bugs causing query engine slowdown in some cases when lazy mode is set. These issues are resolved in H2 master and will become available as a part of the next release (presumably 1.4.198). We need to make lazy mode enabled by default once new version is available (IGNITE-10801). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11278) SQL: Extract query parsing into separate class
Vladimir Ozerov created IGNITE-11278: Summary: SQL: Extract query parsing into separate class Key: IGNITE-11278 URL: https://issues.apache.org/jira/browse/IGNITE-11278 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.8 # Introduce separate command types for SELECT, DML and others commands # Move parsing logic and query cache to separate class # Fix bug with query parallelism when "distributedQueries" flag is modified not for newly created query, but globally. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11280) SQL: Cache all queries, not only two-step
Vladimir Ozerov created IGNITE-11280: Summary: SQL: Cache all queries, not only two-step Key: IGNITE-11280 URL: https://issues.apache.org/jira/browse/IGNITE-11280 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Fix For: 2.8 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11279) SQL: Remove H2's "prepared" from DML plans
Vladimir Ozerov created IGNITE-11279: Summary: SQL: Remove H2's "prepared" from DML plans Key: IGNITE-11279 URL: https://issues.apache.org/jira/browse/IGNITE-11279 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Fix For: 2.8 Currently it is only used to get the list of participating tables. Instead, we should encapsulate this information into {{ParsingResultDml}}. Streamer methods should use our own parser as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11304) SQL: Common caching of both local and distributed query metadata
Vladimir Ozerov created IGNITE-11304: Summary: SQL: Common caching of both local and distributed query metadata Key: IGNITE-11304 URL: https://issues.apache.org/jira/browse/IGNITE-11304 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Currently query metadata is only cached for distributed queries. For local queries it is calculated on every request over and over again. Need to cache it always in {{QueryParserResultSelect}}. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11310) SQL: remove special interaction between query parallelism and distributed joins
Vladimir Ozerov created IGNITE-11310: Summary: SQL: remove special interaction between query parallelism and distributed joins Key: IGNITE-11310 URL: https://issues.apache.org/jira/browse/IGNITE-11310 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.8 Currently we enable so-called "local distributed joins" when query is executed locally with enabled parallelism. This behavior is not needed and needs to be removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11316) SQL: Support partition pruning for local queries
Vladimir Ozerov created IGNITE-11316: Summary: SQL: Support partition pruning for local queries Key: IGNITE-11316 URL: https://issues.apache.org/jira/browse/IGNITE-11316 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Currently it is not supported because extraction happens inside splitter. Local query eithe: # Do not reach splitter at all (no-split case) # Reach splitter, but skip extraction due to missing infrastructure which is to be implemented and tested in the scope of current ticket. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11317) Document that SQL DML statements (UPDATE/MERGE) cannot update key fields
Vladimir Ozerov created IGNITE-11317: Summary: Document that SQL DML statements (UPDATE/MERGE) cannot update key fields Key: IGNITE-11317 URL: https://issues.apache.org/jira/browse/IGNITE-11317 Project: Ignite Issue Type: Task Components: documentation, sql Reporter: Vladimir Ozerov Assignee: Artem Budnikov This is architectural limitation which is unlikely to be resolved in the nearest time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11325) SQL: Single place to start missing caches (H2Utils.checkAndStartNotStartedCache)
Vladimir Ozerov created IGNITE-11325: Summary: SQL: Single place to start missing caches (H2Utils.checkAndStartNotStartedCache) Key: IGNITE-11325 URL: https://issues.apache.org/jira/browse/IGNITE-11325 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Fix For: 2.8 We need to start missing caches for the given SELECT/DML statement because we need affinity info during query planning which is only available for started caches. We need to do the following: # Move the method {{H2Utils.checkAndStartNotStartedCache}} to some common place, e.g. parser, so that it has one and only one usage all over the code base # Make sure that this method doesn't produce multiple network hops: missing caches should be started in a single request if possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11326) SQL: Common parsing logic
Vladimir Ozerov created IGNITE-11326: Summary: SQL: Common parsing logic Key: IGNITE-11326 URL: https://issues.apache.org/jira/browse/IGNITE-11326 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11333) SQL: Deprecate H2 console
Vladimir Ozerov created IGNITE-11333: Summary: SQL: Deprecate H2 console Key: IGNITE-11333 URL: https://issues.apache.org/jira/browse/IGNITE-11333 Project: Ignite Issue Type: Task Reporter: Vladimir Ozerov Assignee: Taras Ledkov This functional is not tested, not supported and may fail with unexpected errors. This affects user experience. Need to disable it and create ticket for relevant documentation update. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11334) SQL: Deprecate SqlQuery
Vladimir Ozerov created IGNITE-11334: Summary: SQL: Deprecate SqlQuery Key: IGNITE-11334 URL: https://issues.apache.org/jira/browse/IGNITE-11334 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Taras Ledkov This API is very limited comparing to {{SqlFieldsQuery}}. Let's deprecate it with proper links to {{SqlFieldsQuery}}. This should be not only deprecation on public API, but removal from examples as well. Separate ticket for documentation is needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11331) SQL: Remove unnecessary parameters binding
Vladimir Ozerov created IGNITE-11331: Summary: SQL: Remove unnecessary parameters binding Key: IGNITE-11331 URL: https://issues.apache.org/jira/browse/IGNITE-11331 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Fix For: 2.8 See usages of {{H2Utils#bindParameters}}. Note that it is used both in SELECT and DML planners without any reason. Let's remove it from there. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11223) SQL: Merge "collectCacheIds" and "processCaches" methods
Vladimir Ozerov created IGNITE-11223: Summary: SQL: Merge "collectCacheIds" and "processCaches" methods Key: IGNITE-11223 URL: https://issues.apache.org/jira/browse/IGNITE-11223 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Both methods are essentially two pieces of the same process - collect cache IDs for the given query, check MVCC mode. But because they are separated, we have unnecessary collection copies, "isEmpty" checks and iterations. Provided that these methods are on a hot path, let's merge them accurately. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11226) SQL: Remove GridQueryIndexing.prepareNativeStatement
Vladimir Ozerov created IGNITE-11226: Summary: SQL: Remove GridQueryIndexing.prepareNativeStatement Key: IGNITE-11226 URL: https://issues.apache.org/jira/browse/IGNITE-11226 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov This method is the only leak of H2 internals to the outer code. Close analysis of code reveals that the only reason we have it is *JDBC metadata*. Need to create a method which will prepare metadata for a statement and return it as a detached object. Most probably we already have all necessary mechanics. This is more about refactoring. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11227) SQL: Streamline DML execution logic
Vladimir Ozerov created IGNITE-11227: Summary: SQL: Streamline DML execution logic Key: IGNITE-11227 URL: https://issues.apache.org/jira/browse/IGNITE-11227 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Currently DML execution logic is overly complex with execution flow being transferred between indexing and DML processor back and forth. Need to simplify it as much as possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11275) SQL: Move all command processing stuff to DDL processor
Vladimir Ozerov created IGNITE-11275: Summary: SQL: Move all command processing stuff to DDL processor Key: IGNITE-11275 URL: https://issues.apache.org/jira/browse/IGNITE-11275 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.8 If command is of non-SELECT/non-DML type, it should be encapsulated inside {{ParsingResult}} as a pair of native/H2 commands and passed to separate processor. This will reduce complexity of {{IgniteH2Indexing}} significantly, as it will be concerned only about SELECT/DML processing and nothing else. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11274) SQL: Make GridCacheSqlQuery immutable
Vladimir Ozerov created IGNITE-11274: Summary: SQL: Make GridCacheSqlQuery immutable Key: IGNITE-11274 URL: https://issues.apache.org/jira/browse/IGNITE-11274 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov The goal of this ticket is to finally make two-step plan fully immutable. First steps we already made in IGNITE-11223, howevere plan's "query" objects are still mutable, what make's plan caching inherently unsafe. # Remove all setters from the message except of {{nodeId}}, which is really needed # Make splitter use another trully immutable object instead of {{GridCacheSqlQuery}} # Copy splitter's object to {{GridCacheSqlQuery}} during reduce -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11115) Binary: rework thread-local binary context to avoid set() operation
Vladimir Ozerov created IGNITE-5: Summary: Binary: rework thread-local binary context to avoid set() operation Key: IGNITE-5 URL: https://issues.apache.org/jira/browse/IGNITE-5 Project: Ignite Issue Type: Task Components: binary Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.8 Currently we call {{ThreadLocal.set()}} on every serialization/deserialization (see {{GridBinaryMarshaller#BINARY_CTX}} usages). This may lead to high CPU usage, especially during SQL query execution. Let's refactor access patterns to work only with {{ThreadLocal.get()}} operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11118) SQL: Ability to resolve partition from argument without H2
Vladimir Ozerov created IGNITE-8: Summary: SQL: Ability to resolve partition from argument without H2 Key: IGNITE-8 URL: https://issues.apache.org/jira/browse/IGNITE-8 Project: Ignite Issue Type: Task Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.8 Currently we rely on H2 to get final partition: we need to convert originally passed argument to expected argument type. We need to write our own code to handle this as H2 code will not be available by thin clients. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11117) SQL: Move partition nodes to core module
Vladimir Ozerov created IGNITE-7: Summary: SQL: Move partition nodes to core module Key: IGNITE-7 URL: https://issues.apache.org/jira/browse/IGNITE-7 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.8 This is needed for further integration with thin clients which do not have dependency on {{indexing}} module. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11134) SQL: Do not wrap key and value objects in GridH2KeyValueRowOnheap
Vladimir Ozerov created IGNITE-11134: Summary: SQL: Do not wrap key and value objects in GridH2KeyValueRowOnheap Key: IGNITE-11134 URL: https://issues.apache.org/jira/browse/IGNITE-11134 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.8 This wrapping is not needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)