[jira] [Created] (IGNITE-24685) Add jmh benchmark for TCP-H queries
Sergey Korotkov created IGNITE-24685: Summary: Add jmh benchmark for TCP-H queries Key: IGNITE-24685 URL: https://issues.apache.org/jira/browse/IGNITE-24685 Project: Ignite Issue Type: Task Reporter: Sergey Korotkov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-24617) Move db constant to NodeFileTree private
[
https://issues.apache.org/jira/browse/IGNITE-24617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17931902#comment-17931902
]
Ignite TC Bot commented on IGNITE-24617:
{panel:title=Branch: [pull/11893/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache (Failover) 1{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=8335681]]
* IgniteCacheFailoverTestSuite:
IgniteAtomicLongChangingTopologySelfTest.testClientQueueCreateCloseFailover -
Test has low fail rate in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/11893/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=8334574&buildTypeId=IgniteTests24Java8_RunAll]
> Move db constant to NodeFileTree private
>
>
> Key: IGNITE-24617
> URL: https://issues.apache.org/jira/browse/IGNITE-24617
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Nikolay Izhikov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-24547) Port speed based throttling from Ignite 2
[
https://issues.apache.org/jira/browse/IGNITE-24547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov reassigned IGNITE-24547:
--
Assignee: Ivan Bessonov
> Port speed based throttling from Ignite 2
> -
>
> Key: IGNITE-24547
> URL: https://issues.apache.org/jira/browse/IGNITE-24547
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
>
> We should port {{{}ThrottlingPolicy#SPEED_BASED{}}}, clean up the code and
> add a bunch of tests for it.
> Do it without new public API, disable it by default.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24687) Use integration test defaults for schema sync settings in colocation tests
[ https://issues.apache.org/jira/browse/IGNITE-24687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-24687: --- Description: # We should use delayDuration of 100ms # metaStorage.idleSyncTimeInterval must be twice as small, that is, 50ms, to prevent waits on schema syncs > Use integration test defaults for schema sync settings in colocation tests > -- > > Key: IGNITE-24687 > URL: https://issues.apache.org/jira/browse/IGNITE-24687 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > # We should use delayDuration of 100ms > # metaStorage.idleSyncTimeInterval must be twice as small, that is, 50ms, to > prevent waits on schema syncs -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24631) Implement zone related methods for SQL fragments mapping
[ https://issues.apache.org/jira/browse/IGNITE-24631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-24631: --- Reviewer: Aleksandr Polovtsev > Implement zone related methods for SQL fragments mapping > > > Key: IGNITE-24631 > URL: https://issues.apache.org/jira/browse/IGNITE-24631 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Ivan Zlenko >Assignee: Ivan Zlenko >Priority: Major > Labels: ignite-3, patch-available > Time Spent: 1h > Remaining Estimate: 0h > > As a part of our efforts to make collocation feature we need to implement > methods related to zone-based assignment calculations for SQL fragments > mapping part of the code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24631) Implement zone related methods for SQL fragments mapping
[ https://issues.apache.org/jira/browse/IGNITE-24631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Zlenko updated IGNITE-24631: - Labels: ignite-3 (was: ignite-3 patch-available) > Implement zone related methods for SQL fragments mapping > > > Key: IGNITE-24631 > URL: https://issues.apache.org/jira/browse/IGNITE-24631 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Ivan Zlenko >Assignee: Ivan Zlenko >Priority: Major > Labels: ignite-3 > Fix For: 3.1 > > Time Spent: 1h > Remaining Estimate: 0h > > As a part of our efforts to make collocation feature we need to implement > methods related to zone-based assignment calculations for SQL fragments > mapping part of the code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24631) Implement zone related methods for SQL fragments mapping
[ https://issues.apache.org/jira/browse/IGNITE-24631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Zlenko updated IGNITE-24631: - Labels: ignite-3 patch-available (was: ignite-3) > Implement zone related methods for SQL fragments mapping > > > Key: IGNITE-24631 > URL: https://issues.apache.org/jira/browse/IGNITE-24631 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Ivan Zlenko >Assignee: Ivan Zlenko >Priority: Major > Labels: ignite-3, patch-available > Time Spent: 1h > Remaining Estimate: 0h > > As a part of our efforts to make collocation feature we need to implement > methods related to zone-based assignment calculations for SQL fragments > mapping part of the code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-24686) REST endpoints return incorrect content type
[
https://issues.apache.org/jira/browse/IGNITE-24686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vadim Pakhnushev updated IGNITE-24686:
--
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> REST endpoints return incorrect content type
>
>
> Key: IGNITE-24686
> URL: https://issues.apache.org/jira/browse/IGNITE-24686
> Project: Ignite
> Issue Type: Bug
> Components: rest
>Reporter: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
>
> Almost all REST API endpoints declares only the {{MediaType.PROBLEM_JSON}} as
> a content type produced by the endpoint. We should add a corresponding
> content type for the successful invocation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-24686) REST endpoints return incorrect content type
Vadim Pakhnushev created IGNITE-24686:
-
Summary: REST endpoints return incorrect content type
Key: IGNITE-24686
URL: https://issues.apache.org/jira/browse/IGNITE-24686
Project: Ignite
Issue Type: Bug
Components: rest
Reporter: Vadim Pakhnushev
Almost all REST API endpoints declares only the {{MediaType.PROBLEM_JSON}} as a
content type produced by the endpoint. We should add a corresponding content
type for the successful invocation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24686) REST endpoints return incorrect content type
[
https://issues.apache.org/jira/browse/IGNITE-24686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vadim Pakhnushev updated IGNITE-24686:
--
Ignite Flags: (was: Release Notes Required)
> REST endpoints return incorrect content type
>
>
> Key: IGNITE-24686
> URL: https://issues.apache.org/jira/browse/IGNITE-24686
> Project: Ignite
> Issue Type: Bug
> Components: rest
>Reporter: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
>
> Almost all REST API endpoints declares only the {{MediaType.PROBLEM_JSON}} as
> a content type produced by the endpoint. We should add a corresponding
> content type for the successful invocation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-24687) Use integration test defaults for schema sync settings in colocation tests
Roman Puchkovskiy created IGNITE-24687: -- Summary: Use integration test defaults for schema sync settings in colocation tests Key: IGNITE-24687 URL: https://issues.apache.org/jira/browse/IGNITE-24687 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-24067) Adjust placement driver for the usage of learners
[
https://issues.apache.org/jira/browse/IGNITE-24067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vadim Kolodin reassigned IGNITE-24067:
--
Assignee: Denis Chudov
> Adjust placement driver for the usage of learners
> -
>
> Key: IGNITE-24067
> URL: https://issues.apache.org/jira/browse/IGNITE-24067
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Motivation*
> Assignments placement driver provides the assignments that it gets from the
> meta storage. So, since the learners will be included into the assignments
> that are written to the meta storage, no additional changes of assignment
> placement driver are required.
> Lease placement driver, however, {*}should be adjusted{*}: primary replica
> should be colocated with consensus group, so the lease placement driver
> should filter the assignments to get only peers before choosing the lease
> candidate.
> Also, if it's impossible to choose a primary replica from stable assignments,
> it should be chosen from the first element of the pending assignment queue.
> *Definition of done*
> * primary replicas are located only on consensus replicas, not learners;
> * if it is impossible to select a primary replica from stable assignments,
> the first element of pending assignments queue should be used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-24067) Adjust placement driver for the usage of learners
[
https://issues.apache.org/jira/browse/IGNITE-24067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vadim Kolodin reassigned IGNITE-24067:
--
Assignee: Vadim Kolodin (was: Denis Chudov)
> Adjust placement driver for the usage of learners
> -
>
> Key: IGNITE-24067
> URL: https://issues.apache.org/jira/browse/IGNITE-24067
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Assignee: Vadim Kolodin
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Motivation*
> Assignments placement driver provides the assignments that it gets from the
> meta storage. So, since the learners will be included into the assignments
> that are written to the meta storage, no additional changes of assignment
> placement driver are required.
> Lease placement driver, however, {*}should be adjusted{*}: primary replica
> should be colocated with consensus group, so the lease placement driver
> should filter the assignments to get only peers before choosing the lease
> candidate.
> Also, if it's impossible to choose a primary replica from stable assignments,
> it should be chosen from the first element of the pending assignment queue.
> *Definition of done*
> * primary replicas are located only on consensus replicas, not learners;
> * if it is impossible to select a primary replica from stable assignments,
> the first element of pending assignments queue should be used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-24683) Remove PageLockListener from non-test classes
[ https://issues.apache.org/jira/browse/IGNITE-24683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17931895#comment-17931895 ] Kirill Tkalenko commented on IGNITE-24683: -- Looks good. > Remove PageLockListener from non-test classes > - > > Key: IGNITE-24683 > URL: https://issues.apache.org/jira/browse/IGNITE-24683 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Time Spent: 3h 20m > Remaining Estimate: 0h > > This listener is only used in tests, for this reason it should not be in > constructor parameters of data structure classes -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-24235) Create Team City test suite for Migration Tools
[ https://issues.apache.org/jira/browse/IGNITE-24235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tiago Marques Godinho reassigned IGNITE-24235: -- Assignee: Tiago Marques Godinho > Create Team City test suite for Migration Tools > --- > > Key: IGNITE-24235 > URL: https://issues.apache.org/jira/browse/IGNITE-24235 > Project: Ignite > Issue Type: Improvement > Components: migration tools >Reporter: Igor Sapego >Assignee: Tiago Marques Godinho >Priority: Major > Labels: ignite-3 > > Let's make sure that we have a TC suite that runs MT tests regularly to > continuously check that nothing is broken. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-24688) Add FILTER_CORRELATE rule to HEP push down list
Maksim Timonin created IGNITE-24688:
---
Summary: Add FILTER_CORRELATE rule to HEP push down list
Key: IGNITE-24688
URL: https://issues.apache.org/jira/browse/IGNITE-24688
Project: Ignite
Issue Type: Improvement
Reporter: Maksim Timonin
Assignee: Maksim Timonin
In the plan below Filter rule is under IgniteTableScan. This leads to memory
overhead. Let's fix it by adding new filter push down rule - Calcite's
FILTER_CORRELATE rule
{code:java}
IgniteColocatedSortAggregate(group=[{0}], ORDER_COUNT=[COUNT()], collation=[[0
ASC-nulls-first]]): rowcount = 187500.0, cumulative cost = IgniteCost
[rowCount=4.500912075E13, cpu=3.60073862443905E13, memory=1.0802194209E14,
io=0.0, network=1.08021936E14], id = 2193
IgniteProject(O_ORDERPRIORITY=[$7]): rowcount = 375000.0, cumulative cost =
IgniteCost [rowCount=4.5009120375E13, cpu=3.60073858693905E13,
memory=1.08021942E14, io=0.0, network=1.08021936E14], id = 2192
IgniteFilter(condition=[AND(>=($6, 1998-01-01), <($6, +(1998-01-01,
3:INTERVAL MONTH)))]): rowcount = 375000.0, cumulative cost = IgniteCost
[rowCount=4.500912E13, cpu=3.60073854943905E13, memory=1.08021942E14, io=0.0,
network=1.08021936E14], id = 2191
IgniteCorrelatedNestedLoopJoin(condition=[true], joinType=[inner],
variablesSet=[[$cor0]], variablesSet=[[0]], correlationVariables=[[$cor0]]):
rowcount = 150.0, cumulative cost = IgniteCost [rowCount=4.50091185E13,
cpu=3.60073794943905E13, memory=1.08021942E14, io=0.0, network=1.08021936E14],
id = 2190
IgniteExchange(distribution=[single]): rowcount = 150.0, cumulative
cost = IgniteCost [rowCount=450.0, cpu=6.849439049732597E7, memory=6.6E7,
io=0.0, network=6.6E7], id = 2185
IgniteSort(sort0=[$7], dir0=[ASC-nulls-first]): rowcount = 150.0,
cumulative cost = IgniteCost [rowCount=300.0, cpu=6.699439049732597E7,
memory=6.6E7, io=0.0, network=0.0], id = 2184
IgniteTableScan(table=[[PUBLIC, ORDERS]]): rowcount = 150.0,
cumulative cost = IgniteCost [rowCount=150.0, cpu=150.0, memory=0.0,
io=0.0, network=0.0], id = 172
IgniteColocatedHashAggregate(group=[{0}]): rowcount = 1.0, cumulative
cost = IgniteCost [rowCount=3.0006075E7, cpu=2.400487E7, memory=7.2014584E7,
io=0.0, network=7.201458E7], id = 2189
IgniteProject(i=[true]): rowcount = 6001215.0, cumulative cost =
IgniteCost [rowCount=2.400486E7, cpu=1.8003655E7, memory=7.201458E7, io=0.0,
network=7.201458E7], id = 2188
IgniteHashIndexSpool(readType=[LAZY], writeType=[EAGER],
searchRow=[[$cor0.O_ORDERKEY, null, null]], condition=[AND(=($0,
$cor0.O_ORDERKEY), <($1, $2))], allowNulls=[false]): rowcount = 6001215.0,
cumulative cost = IgniteCost [rowCount=1.8003645E7, cpu=1.200244E7,
memory=7.201458E7, io=0.0, network=7.201458E7], id = 2187
IgniteExchange(distribution=[single]): rowcount = 6001215.0,
cumulative cost = IgniteCost [rowCount=1.200243E7, cpu=1.200243E7, memory=0.0,
io=0.0, network=7.201458E7], id = 2186
IgniteTableScan(table=[[PUBLIC, LINEITEM]],
requiredColumns=[{2, 13, 14}]): rowcount = 6001215.0, cumulative cost =
IgniteCost [rowCount=6001215.0, cpu=6001215.0, memory=0.0, io=0.0,
network=0.0], id = 224
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24688) Add FILTER_CORRELATE rule to HEP push down list
[
https://issues.apache.org/jira/browse/IGNITE-24688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Timonin updated IGNITE-24688:
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Add FILTER_CORRELATE rule to HEP push down list
> ---
>
> Key: IGNITE-24688
> URL: https://issues.apache.org/jira/browse/IGNITE-24688
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
>
>
> In the plan below Filter rule is under IgniteTableScan. This leads to memory
> overhead. Let's fix it by adding new filter push down rule - Calcite's
> FILTER_CORRELATE rule
>
> {code:java}
> IgniteColocatedSortAggregate(group=[{0}], ORDER_COUNT=[COUNT()],
> collation=[[0 ASC-nulls-first]]): rowcount = 187500.0, cumulative cost =
> IgniteCost [rowCount=4.500912075E13, cpu=3.60073862443905E13,
> memory=1.0802194209E14, io=0.0, network=1.08021936E14], id = 2193
> IgniteProject(O_ORDERPRIORITY=[$7]): rowcount = 375000.0, cumulative cost =
> IgniteCost [rowCount=4.5009120375E13, cpu=3.60073858693905E13,
> memory=1.08021942E14, io=0.0, network=1.08021936E14], id = 2192
> IgniteFilter(condition=[AND(>=($6, 1998-01-01), <($6, +(1998-01-01,
> 3:INTERVAL MONTH)))]): rowcount = 375000.0, cumulative cost = IgniteCost
> [rowCount=4.500912E13, cpu=3.60073854943905E13, memory=1.08021942E14, io=0.0,
> network=1.08021936E14], id = 2191
> IgniteCorrelatedNestedLoopJoin(condition=[true], joinType=[inner],
> variablesSet=[[$cor0]], variablesSet=[[0]], correlationVariables=[[$cor0]]):
> rowcount = 150.0, cumulative cost = IgniteCost [rowCount=4.50091185E13,
> cpu=3.60073794943905E13, memory=1.08021942E14, io=0.0,
> network=1.08021936E14], id = 2190
> IgniteExchange(distribution=[single]): rowcount = 150.0,
> cumulative cost = IgniteCost [rowCount=450.0, cpu=6.849439049732597E7,
> memory=6.6E7, io=0.0, network=6.6E7], id = 2185
> IgniteSort(sort0=[$7], dir0=[ASC-nulls-first]): rowcount =
> 150.0, cumulative cost = IgniteCost [rowCount=300.0,
> cpu=6.699439049732597E7, memory=6.6E7, io=0.0, network=0.0], id = 2184
> IgniteTableScan(table=[[PUBLIC, ORDERS]]): rowcount = 150.0,
> cumulative cost = IgniteCost [rowCount=150.0, cpu=150.0, memory=0.0,
> io=0.0, network=0.0], id = 172
> IgniteColocatedHashAggregate(group=[{0}]): rowcount = 1.0, cumulative
> cost = IgniteCost [rowCount=3.0006075E7, cpu=2.400487E7, memory=7.2014584E7,
> io=0.0, network=7.201458E7], id = 2189
> IgniteProject(i=[true]): rowcount = 6001215.0, cumulative cost =
> IgniteCost [rowCount=2.400486E7, cpu=1.8003655E7, memory=7.201458E7, io=0.0,
> network=7.201458E7], id = 2188
> IgniteHashIndexSpool(readType=[LAZY], writeType=[EAGER],
> searchRow=[[$cor0.O_ORDERKEY, null, null]], condition=[AND(=($0,
> $cor0.O_ORDERKEY), <($1, $2))], allowNulls=[false]): rowcount = 6001215.0,
> cumulative cost = IgniteCost [rowCount=1.8003645E7, cpu=1.200244E7,
> memory=7.201458E7, io=0.0, network=7.201458E7], id = 2187
> IgniteExchange(distribution=[single]): rowcount = 6001215.0,
> cumulative cost = IgniteCost [rowCount=1.200243E7, cpu=1.200243E7,
> memory=0.0, io=0.0, network=7.201458E7], id = 2186
> IgniteTableScan(table=[[PUBLIC, LINEITEM]],
> requiredColumns=[{2, 13, 14}]): rowcount = 6001215.0, cumulative cost =
> IgniteCost [rowCount=6001215.0, cpu=6001215.0, memory=0.0, io=0.0,
> network=0.0], id = 224
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24688) Add FILTER_CORRELATE rule to HEP push down list
[
https://issues.apache.org/jira/browse/IGNITE-24688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Timonin updated IGNITE-24688:
Fix Version/s: 2.18
> Add FILTER_CORRELATE rule to HEP push down list
> ---
>
> Key: IGNITE-24688
> URL: https://issues.apache.org/jira/browse/IGNITE-24688
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
> Fix For: 2.18
>
>
>
> In the plan below Filter rule is under IgniteTableScan. This leads to memory
> overhead. Let's fix it by adding new filter push down rule - Calcite's
> FILTER_CORRELATE rule
>
> {code:java}
> IgniteColocatedSortAggregate(group=[{0}], ORDER_COUNT=[COUNT()],
> collation=[[0 ASC-nulls-first]]): rowcount = 187500.0, cumulative cost =
> IgniteCost [rowCount=4.500912075E13, cpu=3.60073862443905E13,
> memory=1.0802194209E14, io=0.0, network=1.08021936E14], id = 2193
> IgniteProject(O_ORDERPRIORITY=[$7]): rowcount = 375000.0, cumulative cost =
> IgniteCost [rowCount=4.5009120375E13, cpu=3.60073858693905E13,
> memory=1.08021942E14, io=0.0, network=1.08021936E14], id = 2192
> IgniteFilter(condition=[AND(>=($6, 1998-01-01), <($6, +(1998-01-01,
> 3:INTERVAL MONTH)))]): rowcount = 375000.0, cumulative cost = IgniteCost
> [rowCount=4.500912E13, cpu=3.60073854943905E13, memory=1.08021942E14, io=0.0,
> network=1.08021936E14], id = 2191
> IgniteCorrelatedNestedLoopJoin(condition=[true], joinType=[inner],
> variablesSet=[[$cor0]], variablesSet=[[0]], correlationVariables=[[$cor0]]):
> rowcount = 150.0, cumulative cost = IgniteCost [rowCount=4.50091185E13,
> cpu=3.60073794943905E13, memory=1.08021942E14, io=0.0,
> network=1.08021936E14], id = 2190
> IgniteExchange(distribution=[single]): rowcount = 150.0,
> cumulative cost = IgniteCost [rowCount=450.0, cpu=6.849439049732597E7,
> memory=6.6E7, io=0.0, network=6.6E7], id = 2185
> IgniteSort(sort0=[$7], dir0=[ASC-nulls-first]): rowcount =
> 150.0, cumulative cost = IgniteCost [rowCount=300.0,
> cpu=6.699439049732597E7, memory=6.6E7, io=0.0, network=0.0], id = 2184
> IgniteTableScan(table=[[PUBLIC, ORDERS]]): rowcount = 150.0,
> cumulative cost = IgniteCost [rowCount=150.0, cpu=150.0, memory=0.0,
> io=0.0, network=0.0], id = 172
> IgniteColocatedHashAggregate(group=[{0}]): rowcount = 1.0, cumulative
> cost = IgniteCost [rowCount=3.0006075E7, cpu=2.400487E7, memory=7.2014584E7,
> io=0.0, network=7.201458E7], id = 2189
> IgniteProject(i=[true]): rowcount = 6001215.0, cumulative cost =
> IgniteCost [rowCount=2.400486E7, cpu=1.8003655E7, memory=7.201458E7, io=0.0,
> network=7.201458E7], id = 2188
> IgniteHashIndexSpool(readType=[LAZY], writeType=[EAGER],
> searchRow=[[$cor0.O_ORDERKEY, null, null]], condition=[AND(=($0,
> $cor0.O_ORDERKEY), <($1, $2))], allowNulls=[false]): rowcount = 6001215.0,
> cumulative cost = IgniteCost [rowCount=1.8003645E7, cpu=1.200244E7,
> memory=7.201458E7, io=0.0, network=7.201458E7], id = 2187
> IgniteExchange(distribution=[single]): rowcount = 6001215.0,
> cumulative cost = IgniteCost [rowCount=1.200243E7, cpu=1.200243E7,
> memory=0.0, io=0.0, network=7.201458E7], id = 2186
> IgniteTableScan(table=[[PUBLIC, LINEITEM]],
> requiredColumns=[{2, 13, 14}]): rowcount = 6001215.0, cumulative cost =
> IgniteCost [rowCount=6001215.0, cpu=6001215.0, memory=0.0, io=0.0,
> network=0.0], id = 224
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-24688) Add FILTER_CORRELATE rule to HEP push down list
[
https://issues.apache.org/jira/browse/IGNITE-24688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Timonin updated IGNITE-24688:
Description:
In the plan below Filter rule is under IgniteTableScan. This leads to memory
overhead. Let's fix it by adding new filter push down rule - Calcite's
FILTER_CORRELATE rule
{code:java}
IgniteColocatedSortAggregate(group=[{0}], ORDER_COUNT=[COUNT()], collation=[[0
ASC-nulls-first]]):
IgniteProject(O_ORDERPRIORITY=[$7])
IgniteFilter(condition=[AND(>=($6, 1998-01-01), <($6, +(1998-01-01,
3:INTERVAL MONTH)))])
IgniteCorrelatedNestedLoopJoin(condition=[true], joinType=[inner],
variablesSet=[[$cor0]], variablesSet=[[0]], correlationVariables=[[$cor0]])
IgniteExchange(distribution=[single])
IgniteSort(sort0=[$7], dir0=[ASC-nulls-first])
IgniteTableScan(table=[[PUBLIC, ORDERS]])
IgniteColocatedHashAggregate(group=[{0}])
IgniteProject(i=[true])
IgniteHashIndexSpool(readType=[LAZY], writeType=[EAGER],
searchRow=[[$cor0.O_ORDERKEY, null, null]], condition=[AND(=($0,
$cor0.O_ORDERKEY), <($1, $2))], allowNulls=[false])
IgniteExchange(distribution=[single])
IgniteTableScan(table=[[PUBLIC, LINEITEM]],
requiredColumns=[{2, 13, 14}])
{code}
was:
In the plan below Filter rule is under IgniteTableScan. This leads to memory
overhead. Let's fix it by adding new filter push down rule - Calcite's
FILTER_CORRELATE rule
{code:java}
IgniteColocatedSortAggregate(group=[{0}], ORDER_COUNT=[COUNT()], collation=[[0
ASC-nulls-first]]): rowcount = 187500.0, cumulative cost = IgniteCost
[rowCount=4.500912075E13, cpu=3.60073862443905E13, memory=1.0802194209E14,
io=0.0, network=1.08021936E14], id = 2193
IgniteProject(O_ORDERPRIORITY=[$7]): rowcount = 375000.0, cumulative cost =
IgniteCost [rowCount=4.5009120375E13, cpu=3.60073858693905E13,
memory=1.08021942E14, io=0.0, network=1.08021936E14], id = 2192
IgniteFilter(condition=[AND(>=($6, 1998-01-01), <($6, +(1998-01-01,
3:INTERVAL MONTH)))]): rowcount = 375000.0, cumulative cost = IgniteCost
[rowCount=4.500912E13, cpu=3.60073854943905E13, memory=1.08021942E14, io=0.0,
network=1.08021936E14], id = 2191
IgniteCorrelatedNestedLoopJoin(condition=[true], joinType=[inner],
variablesSet=[[$cor0]], variablesSet=[[0]], correlationVariables=[[$cor0]]):
rowcount = 150.0, cumulative cost = IgniteCost [rowCount=4.50091185E13,
cpu=3.60073794943905E13, memory=1.08021942E14, io=0.0, network=1.08021936E14],
id = 2190
IgniteExchange(distribution=[single]): rowcount = 150.0, cumulative
cost = IgniteCost [rowCount=450.0, cpu=6.849439049732597E7, memory=6.6E7,
io=0.0, network=6.6E7], id = 2185
IgniteSort(sort0=[$7], dir0=[ASC-nulls-first]): rowcount = 150.0,
cumulative cost = IgniteCost [rowCount=300.0, cpu=6.699439049732597E7,
memory=6.6E7, io=0.0, network=0.0], id = 2184
IgniteTableScan(table=[[PUBLIC, ORDERS]]): rowcount = 150.0,
cumulative cost = IgniteCost [rowCount=150.0, cpu=150.0, memory=0.0,
io=0.0, network=0.0], id = 172
IgniteColocatedHashAggregate(group=[{0}]): rowcount = 1.0, cumulative
cost = IgniteCost [rowCount=3.0006075E7, cpu=2.400487E7, memory=7.2014584E7,
io=0.0, network=7.201458E7], id = 2189
IgniteProject(i=[true]): rowcount = 6001215.0, cumulative cost =
IgniteCost [rowCount=2.400486E7, cpu=1.8003655E7, memory=7.201458E7, io=0.0,
network=7.201458E7], id = 2188
IgniteHashIndexSpool(readType=[LAZY], writeType=[EAGER],
searchRow=[[$cor0.O_ORDERKEY, null, null]], condition=[AND(=($0,
$cor0.O_ORDERKEY), <($1, $2))], allowNulls=[false]): rowcount = 6001215.0,
cumulative cost = IgniteCost [rowCount=1.8003645E7, cpu=1.200244E7,
memory=7.201458E7, io=0.0, network=7.201458E7], id = 2187
IgniteExchange(distribution=[single]): rowcount = 6001215.0,
cumulative cost = IgniteCost [rowCount=1.200243E7, cpu=1.200243E7, memory=0.0,
io=0.0, network=7.201458E7], id = 2186
IgniteTableScan(table=[[PUBLIC, LINEITEM]],
requiredColumns=[{2, 13, 14}]): rowcount = 6001215.0, cumulative cost =
IgniteCost [rowCount=6001215.0, cpu=6001215.0, memory=0.0, io=0.0,
network=0.0], id = 224
{code}
> Add FILTER_CORRELATE rule to HEP push down list
> ---
>
> Key: IGNITE-24688
> URL: https://issues.apache.org/jira/browse/IGNITE-24688
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
> Labels: ise
> Fix For: 2.18
>
>
>
> In the plan below Filter rule is under IgniteTableScan. This leads to memory
> overhead. Let's fix it by adding new filter push down rule - Calcite's
> FILTER_CORRELATE ru
[jira] [Updated] (IGNITE-24688) Add FILTER_CORRELATE rule to HEP push down list
[
https://issues.apache.org/jira/browse/IGNITE-24688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Timonin updated IGNITE-24688:
Labels: ise (was: )
> Add FILTER_CORRELATE rule to HEP push down list
> ---
>
> Key: IGNITE-24688
> URL: https://issues.apache.org/jira/browse/IGNITE-24688
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
> Labels: ise
> Fix For: 2.18
>
>
>
> In the plan below Filter rule is under IgniteTableScan. This leads to memory
> overhead. Let's fix it by adding new filter push down rule - Calcite's
> FILTER_CORRELATE rule
>
> {code:java}
> IgniteColocatedSortAggregate(group=[{0}], ORDER_COUNT=[COUNT()],
> collation=[[0 ASC-nulls-first]]): rowcount = 187500.0, cumulative cost =
> IgniteCost [rowCount=4.500912075E13, cpu=3.60073862443905E13,
> memory=1.0802194209E14, io=0.0, network=1.08021936E14], id = 2193
> IgniteProject(O_ORDERPRIORITY=[$7]): rowcount = 375000.0, cumulative cost =
> IgniteCost [rowCount=4.5009120375E13, cpu=3.60073858693905E13,
> memory=1.08021942E14, io=0.0, network=1.08021936E14], id = 2192
> IgniteFilter(condition=[AND(>=($6, 1998-01-01), <($6, +(1998-01-01,
> 3:INTERVAL MONTH)))]): rowcount = 375000.0, cumulative cost = IgniteCost
> [rowCount=4.500912E13, cpu=3.60073854943905E13, memory=1.08021942E14, io=0.0,
> network=1.08021936E14], id = 2191
> IgniteCorrelatedNestedLoopJoin(condition=[true], joinType=[inner],
> variablesSet=[[$cor0]], variablesSet=[[0]], correlationVariables=[[$cor0]]):
> rowcount = 150.0, cumulative cost = IgniteCost [rowCount=4.50091185E13,
> cpu=3.60073794943905E13, memory=1.08021942E14, io=0.0,
> network=1.08021936E14], id = 2190
> IgniteExchange(distribution=[single]): rowcount = 150.0,
> cumulative cost = IgniteCost [rowCount=450.0, cpu=6.849439049732597E7,
> memory=6.6E7, io=0.0, network=6.6E7], id = 2185
> IgniteSort(sort0=[$7], dir0=[ASC-nulls-first]): rowcount =
> 150.0, cumulative cost = IgniteCost [rowCount=300.0,
> cpu=6.699439049732597E7, memory=6.6E7, io=0.0, network=0.0], id = 2184
> IgniteTableScan(table=[[PUBLIC, ORDERS]]): rowcount = 150.0,
> cumulative cost = IgniteCost [rowCount=150.0, cpu=150.0, memory=0.0,
> io=0.0, network=0.0], id = 172
> IgniteColocatedHashAggregate(group=[{0}]): rowcount = 1.0, cumulative
> cost = IgniteCost [rowCount=3.0006075E7, cpu=2.400487E7, memory=7.2014584E7,
> io=0.0, network=7.201458E7], id = 2189
> IgniteProject(i=[true]): rowcount = 6001215.0, cumulative cost =
> IgniteCost [rowCount=2.400486E7, cpu=1.8003655E7, memory=7.201458E7, io=0.0,
> network=7.201458E7], id = 2188
> IgniteHashIndexSpool(readType=[LAZY], writeType=[EAGER],
> searchRow=[[$cor0.O_ORDERKEY, null, null]], condition=[AND(=($0,
> $cor0.O_ORDERKEY), <($1, $2))], allowNulls=[false]): rowcount = 6001215.0,
> cumulative cost = IgniteCost [rowCount=1.8003645E7, cpu=1.200244E7,
> memory=7.201458E7, io=0.0, network=7.201458E7], id = 2187
> IgniteExchange(distribution=[single]): rowcount = 6001215.0,
> cumulative cost = IgniteCost [rowCount=1.200243E7, cpu=1.200243E7,
> memory=0.0, io=0.0, network=7.201458E7], id = 2186
> IgniteTableScan(table=[[PUBLIC, LINEITEM]],
> requiredColumns=[{2, 13, 14}]): rowcount = 6001215.0, cumulative cost =
> IgniteCost [rowCount=6001215.0, cpu=6001215.0, memory=0.0, io=0.0,
> network=0.0], id = 224
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-24688) Add FILTER_CORRELATE rule to HEP push down list
[
https://issues.apache.org/jira/browse/IGNITE-24688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17932153#comment-17932153
]
Ignite TC Bot commented on IGNITE-24688:
{panel:title=Branch: [pull/11905/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11905/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=8336065&buildTypeId=IgniteTests24Java8_RunAll]
> Add FILTER_CORRELATE rule to HEP push down list
> ---
>
> Key: IGNITE-24688
> URL: https://issues.apache.org/jira/browse/IGNITE-24688
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
> Labels: ise
> Fix For: 2.18
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
>
> In the plan below Filter rule is under IgniteTableScan. This leads to memory
> overhead. Let's fix it by adding new filter push down rule - Calcite's
> FILTER_CORRELATE rule
>
> {code:java}
> IgniteColocatedSortAggregate(group=[{0}], ORDER_COUNT=[COUNT()],
> collation=[[0 ASC-nulls-first]]):
> IgniteProject(O_ORDERPRIORITY=[$7])
> IgniteFilter(condition=[AND(>=($6, 1998-01-01), <($6, +(1998-01-01,
> 3:INTERVAL MONTH)))])
> IgniteCorrelatedNestedLoopJoin(condition=[true], joinType=[inner],
> variablesSet=[[$cor0]], variablesSet=[[0]], correlationVariables=[[$cor0]])
> IgniteExchange(distribution=[single])
> IgniteSort(sort0=[$7], dir0=[ASC-nulls-first])
> IgniteTableScan(table=[[PUBLIC, ORDERS]])
> IgniteColocatedHashAggregate(group=[{0}])
> IgniteProject(i=[true])
> IgniteHashIndexSpool(readType=[LAZY], writeType=[EAGER],
> searchRow=[[$cor0.O_ORDERKEY, null, null]], condition=[AND(=($0,
> $cor0.O_ORDERKEY), <($1, $2))], allowNulls=[false])
> IgniteExchange(distribution=[single])
> IgniteTableScan(table=[[PUBLIC, LINEITEM]],
> requiredColumns=[{2, 13, 14}])
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-24380) Move PartitionReplicaListener#ensureReplicaIsPrimary to ZonePartitionReplicaListener
[ https://issues.apache.org/jira/browse/IGNITE-24380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy reassigned IGNITE-24380: -- Assignee: Roman Puchkovskiy (was: Alexander Lapin) > Move PartitionReplicaListener#ensureReplicaIsPrimary to > ZonePartitionReplicaListener > > > Key: IGNITE-24380 > URL: https://issues.apache.org/jira/browse/IGNITE-24380 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > h3. Motivation > Some replica requests are expected to be processed on primary replica only, > e.g. all RW requests. Some requests will behave differently regarding on > whether they are handled on primary or not. Thus we should move > ensureReplicaIsPrimary to ZonePartitionReplicaListener and eliminate > corresponding checks on PartitionReplicaListener side in case of colocation > track. > h3. Definition of Done > * PartitionReplicaListener#ensureReplicaIsPrimary copied to > ZonePartitionReplicaListener along with all dependencies. > * ensureReplicaIsPrimary call is skipped on the PartitionReplicaListener in > case of collocation track. > * Corresponding tests are written in order to check that > PrimaryReplicaMissException is thrown. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-24664) Calcite engine. Use _key_PK index scan instead of hash index scan if possible
[
https://issues.apache.org/jira/browse/IGNITE-24664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17932171#comment-17932171
]
Aleksey Plekhanov commented on IGNITE-24664:
Local performance test:
Before fix:
{noformat}
Benchmark (engine) Mode Cnt Score Error Units
JmhSqlBenchmark.querySimpleUnique H2 thrpt 3 192,254 ± 3,643 ops/s
JmhSqlBenchmark.querySimpleUnique CALCITE thrpt 3 147,601 ± 28,635 ops/s
{noformat}
After fix:
{noformat}
Benchmark (engine) Mode Cnt Score Error Units
JmhSqlBenchmark.querySimpleUnique H2 thrpt 3 193,708 ± 23,837 ops/s
JmhSqlBenchmark.querySimpleUnique CALCITE thrpt 3 160,935 ± 10,954 ops/s
{noformat}
> Calcite engine. Use _key_PK index scan instead of hash index scan if possible
> -
>
> Key: IGNITE-24664
> URL: https://issues.apache.org/jira/browse/IGNITE-24664
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, ise
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Looks like _key_PK index scan is more effective than hash index scan. Hash
> index scan requires also entity type check, but _key_PK index scan only built
> for required entity type, so type check can be skipped.
> H2 engine uses PK index scan for table scans (see H2TableScanIndex.delegate()
> method).
> Calcite engine should also use PK index scan when indexes are in correct
> state.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-24664) Calcite engine. Use _key_PK index scan instead of hash index scan if possible
[
https://issues.apache.org/jira/browse/IGNITE-24664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17932172#comment-17932172
]
Ignite TC Bot commented on IGNITE-24664:
{panel:title=Branch: [pull/11900/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11900/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=8330663&buildTypeId=IgniteTests24Java8_RunAll]
> Calcite engine. Use _key_PK index scan instead of hash index scan if possible
> -
>
> Key: IGNITE-24664
> URL: https://issues.apache.org/jira/browse/IGNITE-24664
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, ise
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Looks like _key_PK index scan is more effective than hash index scan. Hash
> index scan requires also entity type check, but _key_PK index scan only built
> for required entity type, so type check can be skipped.
> H2 engine uses PK index scan for table scans (see H2TableScanIndex.delegate()
> method).
> Calcite engine should also use PK index scan when indexes are in correct
> state.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-24563) Sql. Add tests to ensure catalog object serialization backward compatibility
[ https://issues.apache.org/jira/browse/IGNITE-24563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov reassigned IGNITE-24563: - Assignee: Maksim Zhuravkov > Sql. Add tests to ensure catalog object serialization backward compatibility > > > Key: IGNITE-24563 > URL: https://issues.apache.org/jira/browse/IGNITE-24563 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0 >Reporter: Pavel Pereslegin >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > Fix For: 3.1 > > > We need to add tests to ensure that we can correctly deserialize catalog > objects in AI 3.1 from a snapshot created in AI 3.0. > Suggestion, > Create generator which will generate two root entries: > 1. SnapshotEntry that includes all possible descriptors. > 2. VersionedUpdate that includes all possible update entries with all > possible descriptors. > Serialize resulted SnapshotEntry into a byte array. > Serialize resulted VersionedUpdate into a byte array. > Run such generator on AI 3.0.0 and get two binaries snapshot-entry.bin and > versioned-update.bin. > These snapshots must be placed into new resources folder in catalog module. > For example: > compatibility/ai-3.0.0/snapshot-entry.bin > compatibility/ai-3.0.0/versioned-update.bin > Test 1 > Ensure that we able to deserialize all objects from snapshots. Verify objects > contents with objects from generator. > Test 2 > Run generator on current code base and serialize all objects with version=1, > result byte array must equal to snapshot data. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-24672) Sensitive data gets logged when doing CMG disaster recovery
[
https://issues.apache.org/jira/browse/IGNITE-24672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17932164#comment-17932164
]
Kirill Tkalenko commented on IGNITE-24672:
--
Looks good.
> Sensitive data gets logged when doing CMG disaster recovery
> ---
>
> Key: IGNITE-24672
> URL: https://issues.apache.org/jira/browse/IGNITE-24672
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The log looks like this:
>
> [2025-02-28T08:57:04,437][INFO
> ][ForkJoinPool.commonPool-worker-6][ClusterManagementGroupManager] Found a
> ResetClusterMessage in storage, going to do cluster reset
> [message=ResetClusterMessageImpl
> [clusterId=5b59f125-97dc-4cc2-bc0e-812308ed4402, clusterName=cluster,
> conductor=null, currentMetaStorageNodes=HashSet [node2],
> formerClusterIds=ArrayList [db553d5c-fa0f-40bb-8402-2527abe57b56],
> initialClusterConfiguration=ignite\{metaStorage{idleSyncTimeInterval=50},replication\{idleSafeTimePropagationDuration=100},schemaSync\{delayDuration=100,maxClockSkew=7},security\{authentication{providers=[{name=default,type=basic,users=[{password=ignite,username=ignite}]}]}}},
> metastorageReplicationFactor=null, newCmgNodes=HashSet [node2],
> participatingNodes=null]]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-24526) Move PartitionReplicaListener#processRequest to ZonePartitionReplicaListener
[ https://issues.apache.org/jira/browse/IGNITE-24526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy reassigned IGNITE-24526: -- Assignee: Roman Puchkovskiy > Move PartitionReplicaListener#processRequest to ZonePartitionReplicaListener > > > Key: IGNITE-24526 > URL: https://issues.apache.org/jira/browse/IGNITE-24526 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-24664) Calcite engine. Use _key_PK index scan instead of hash index scan if possible
[
https://issues.apache.org/jira/browse/IGNITE-24664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17932171#comment-17932171
]
Aleksey Plekhanov edited comment on IGNITE-24664 at 3/4/25 6:57 AM:
Local performance test:
Before fix:
{noformat}
Benchmark (engine) Mode Cnt Score Error Units
JmhSqlBenchmark.querySimpleUnique H2 thrpt 3 192,254 ± 3,643 ops/s
JmhSqlBenchmark.querySimpleUnique CALCITE thrpt 3 147,601 ± 28,635 ops/s
{noformat}
After fix:
{noformat}
Benchmark (engine) Mode Cnt Score Error Units
JmhSqlBenchmark.querySimpleUnique H2 thrpt 3 193,708 ± 23,837 ops/s
JmhSqlBenchmark.querySimpleUnique CALCITE thrpt 3 160,935 ± 10,954 ops/s
{noformat}
was (Author: alex_pl):
Local performance test:
Before fix:
{noformat}
Benchmark (engine) Mode Cnt Score Error Units
JmhSqlBenchmark.querySimpleUnique H2 thrpt 3 192,254 ± 3,643 ops/s
JmhSqlBenchmark.querySimpleUnique CALCITE thrpt 3 147,601 ± 28,635 ops/s
{noformat}
After fix:
{noformat}
Benchmark (engine) Mode Cnt Score Error Units
JmhSqlBenchmark.querySimpleUnique H2 thrpt 3 193,708 ± 23,837 ops/s
JmhSqlBenchmark.querySimpleUnique CALCITE thrpt 3 160,935 ± 10,954 ops/s
{noformat}
> Calcite engine. Use _key_PK index scan instead of hash index scan if possible
> -
>
> Key: IGNITE-24664
> URL: https://issues.apache.org/jira/browse/IGNITE-24664
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, ise
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Looks like _key_PK index scan is more effective than hash index scan. Hash
> index scan requires also entity type check, but _key_PK index scan only built
> for required entity type, so type check can be skipped.
> H2 engine uses PK index scan for table scans (see H2TableScanIndex.delegate()
> method).
> Calcite engine should also use PK index scan when indexes are in correct
> state.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
