[jira] [Created] (IGNITE-11701) SQL: Reflect in documentation change of system views schema from "IGNITE" to "SYS"
Vladimir Ozerov created IGNITE-11701: Summary: SQL: Reflect in documentation change of system views schema from "IGNITE" to "SYS" Key: IGNITE-11701 URL: https://issues.apache.org/jira/browse/IGNITE-11701 Project: Ignite Issue Type: Task Components: documentation Reporter: Vladimir Ozerov Assignee: Artem Budnikov Fix For: 2.8 Previously all system views were located in "IGNITE" schema. Now we moved them to "SYS" because this is more intuitive and consistent with other database vendors. Need to do two things: # Updated documentation of system views: change "IGNITE" schema to "SYS" # Add a balloon informing users that before AI 2.8 system views were located in "IGNITE" schema and that previous behavior could be forced with "-DIGNITE_SQL_SYSTEM_SCHEMA_NAME_IGNITE=true" system property. -- 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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-11212) SQL: Merge affinity collocation models for partition pruning and distributed joins
Vladimir Ozerov created IGNITE-11212: Summary: SQL: Merge affinity collocation models for partition pruning and distributed joins Key: IGNITE-11212 URL: https://issues.apache.org/jira/browse/IGNITE-11212 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Currently we have two different types of tree models for partition pruning and distributed joins. First, this leads to code duplication. Second, they subtle semantic differences harboring hidden bugs. Let's try to merge them into a single model which is built with the same set of rules. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11211) SQL: Rework connection pool
Vladimir Ozerov created IGNITE-11211: Summary: SQL: Rework connection pool Key: IGNITE-11211 URL: https://issues.apache.org/jira/browse/IGNITE-11211 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Currently we have very complex multi-level connection pool. Instead, we may have a single concurrent queue with shared connections which are acquired and released by threads as needed. As an optimization we may optionally attach connections to thread-local storage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11210) SQL: Introduce common logical execution plan for all query types
Vladimir Ozerov created IGNITE-11210:
Summary: SQL: Introduce common logical execution plan for all
query types
Key: IGNITE-11210
URL: https://issues.apache.org/jira/browse/IGNITE-11210
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Vladimir Ozerov
At the moment we have a lot of various cached stuff used for different SQL
types (prepared statements for local queries, two-step queries for distributed
queries, update plan for DML).
What we need instead of having multiple caches is to create common execution
plan for every query, which will hold both DML and SELECT stuff. Approximate
content of such a plan:
# Two-step plan
# DML plan
# Partition pruning stuff
# May be even cached physical node distribution (for reduce queries) for the
given {{AffinityTopologyVersion}}
# Probably {{AffinityTopologyVersion}}
Then we will perform a single plan lookup/build per every query execution. In
future we will probably display these plans in SQL views.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11208) SQL: Move reservations from QueryContext to MapQueryResult
Vladimir Ozerov created IGNITE-11208:
Summary: SQL: Move reservations from QueryContext to MapQueryResult
Key: IGNITE-11208
URL: https://issues.apache.org/jira/browse/IGNITE-11208
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Vladimir Ozerov
It is absolutely unclear why reservations are handled inside {{QueryContext}}.
First, they belong to specific {{MapQueryResult}}, not some thread-local stuff.
Second, inside {{QueryContext}} logic they are cleared only for requests with
distributed joins. Why?
Let's remove this weird stuff.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11209) SQL: streamline DML execution logic
Vladimir Ozerov created IGNITE-11209: Summary: SQL: streamline DML execution logic Key: IGNITE-11209 URL: https://issues.apache.org/jira/browse/IGNITE-11209 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-11207) SQL: Remove MapNodeResults class
Vladimir Ozerov created IGNITE-11207:
Summary: SQL: Remove MapNodeResults class
Key: IGNITE-11207
URL: https://issues.apache.org/jira/browse/IGNITE-11207
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Vladimir Ozerov
Fix For: 2.8
This class holds results for a specific node. Let's remove it and refactor
associated code with the following goals in mind:
# Performance: one CHM lookup instead of two
# Uniformity: move both SELECT and DML under the same {{MapQueryResult}}
umbrella
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11206) SQL: Merge execution flow for local and map queries
Vladimir Ozerov created IGNITE-11206: Summary: SQL: Merge execution flow for local and map queries Key: IGNITE-11206 URL: https://issues.apache.org/jira/browse/IGNITE-11206 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Currently MAP and LOCAL queries are executed in completely different fashion. This leads to a number of bugs and discrepancies, not to mention obvious code duplication: # Local queries do not reserve partitions # Security checks might be missed for local queries (need to double-check). # Different event firing logic Let's merge both flows: # Check security and other prerequisites # Reserve partitions # Get connection # Execute, firing events along the way # Release connection # Release partitions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11203) SQL: global refactoring
Vladimir Ozerov created IGNITE-11203: Summary: SQL: global refactoring Key: IGNITE-11203 URL: https://issues.apache.org/jira/browse/IGNITE-11203 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Over the years of existence SQL business logic became overly complex as we never invested enough time into technical debt. Most prominent features that led to over-complication are: # Distributed joins # Subqueries in spliiter # MVCC # Query cancel feature # DML As a result currently it is too difficult to add new features to the product: we have to spend a lot time figuring what if going on, and loose a lot on introduced bugs. General idea of this initiative is to streamline query execution engine as much as possible. The most important things to consider: # Simplify H2 connection management: simple pooling, avoid exposing connection when possible # Execute MAP and LOCAL queries through the same flow # Avoid zig-zag code flow in DML stuff # Try to merge partition pruning and distributed join cost calculation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11202) SQL: Move partition reservation logic to separate class
Vladimir Ozerov created IGNITE-11202:
Summary: SQL: Move partition reservation logic to separate class
Key: IGNITE-11202
URL: https://issues.apache.org/jira/browse/IGNITE-11202
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Fix For: 2.8
Currently associated logic is located inside {{GridMapQueryExecutor}}. This is
wrong because partitions should be reserved and then released for both local
and distributed queries. To allow for smooth merge of "map" and "local" queries
in future, it is necessary to move this common logic into a separate place
which is independent of {{GridMapQueryExecutor}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11200) SQL: query contexts should not be static
Vladimir Ozerov created IGNITE-11200: Summary: SQL: query contexts should not be static Key: IGNITE-11200 URL: https://issues.apache.org/jira/browse/IGNITE-11200 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.8 Currently query contexts are static and as a result over complicated. Need to make them instance-bound and remove static. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11185) SQL: Move distributed joins code from base index to H2TreeIndex
Vladimir Ozerov created IGNITE-11185:
Summary: SQL: Move distributed joins code from base index to
H2TreeIndex
Key: IGNITE-11185
URL: https://issues.apache.org/jira/browse/IGNITE-11185
Project: Ignite
Issue Type: Task
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Fix For: 2.8
{{H2TreeIndex}} is the only implementation concerned with distributed joins.
Let's move associated from {{GridH2IndexBase}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11180) SQL: give more sensible names to reducer classes
Vladimir Ozerov created IGNITE-11180: Summary: SQL: give more sensible names to reducer classes Key: IGNITE-11180 URL: https://issues.apache.org/jira/browse/IGNITE-11180 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.8 # Rename classes in accordance to map/reduce approach to simplify further development # Remove dead code in reducer logic -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11169) SQL: Remove collocation model-related code from GridH2QueryContext
Vladimir Ozerov created IGNITE-11169: Summary: SQL: Remove collocation model-related code from GridH2QueryContext Key: IGNITE-11169 URL: https://issues.apache.org/jira/browse/IGNITE-11169 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.8 This should be located in splitter logic instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11160) SQL: Create light-weight row for read-only rows
Vladimir Ozerov created IGNITE-11160:
Summary: SQL: Create light-weight row for read-only rows
Key: IGNITE-11160
URL: https://issues.apache.org/jira/browse/IGNITE-11160
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Fix For: 2.8
In order to minimize memory overhead during query execution we can create
simplified version of {{GridH2KeyValueRowOnheap}} which will not hold reference
to original row. Also we can remove value cache as it is never used during
SELECT execution.
--
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)
[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-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-11083) SQL: Extract query model from splitter
Vladimir Ozerov created IGNITE-11083: Summary: SQL: Extract query model from splitter Key: IGNITE-11083 URL: https://issues.apache.org/jira/browse/IGNITE-11083 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.8 We will need a common query model with join/subquery info for future splitter and partition pruning improvements. Let's extract accurately the model from splitter aiming to reuse it for partition pruning in future. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11057) Document new SQL system view "CACHE_GROUPS_IO"
Vladimir Ozerov created IGNITE-11057:
Summary: Document new SQL system view "CACHE_GROUPS_IO"
Key: IGNITE-11057
URL: https://issues.apache.org/jira/browse/IGNITE-11057
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\SqlSystemViewCacheGroupsIOStatistics.java}}
# {{GROUP_ID}} - cache group ID
# {{GROUP_ID}} - cache group name
# {{PHYSICAL_READS}} - number of physical reads (i.e. block read from disk) for
the given group
# {{LOGICAL_READS}} - number of logical reads (i.e. from buffer cache) for the
given group.
--
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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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)
