[jira] [Updated] (IGNITE-21281) Sql. Partition pruning. Integrate static partition pruning into MODIFY statements execution pipeline.
[
https://issues.apache.org/jira/browse/IGNITE-21281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-21281:
--
Description:
Update PartitionExtractor introduced in
https://issues.apache.org/jira/browse/IGNITE-21277 to compile pruning metadata
for DML operations.
In order to that we need to extract values of colocation key columns from input
operators to ModifyNodes:
- For operations that do accept scan operation (e.g. plain INSERT), such
information is included in Values and Projection operators (to get values for
DEFAULT expression).
- For that accept scan operation, we should use pruning metadata provided by a
scan operator.
*Some examples*
Plain insert:
{code:java}
INSERT INTO t (colo_col1, colo_col2) VALUES (1, 2), (3, 4)
Partition pruning metadata: t = [ (col_c1 = 1, col_c2 = 2) || (col_c1 = 3,
col_c2 = 4)]
{code}
Plain update
{code:java}
UPDATE t SET col = 100 WHERE pk = 42
Partition pruning metadata: t = [ (pk = 42) ] // Uses metadata provided by a
scan operation
{code}
Delete
{code:java}
DELETE FROM t WHERE pk = 42
Partition pruning metadata: t = [ (pk = 42) ] // Uses metadata provided by a
scan operation
{code}
After this issue is resolved, partition pruning should work for INSERT, UPDATE,
MERGE, and DELETE statements.
was:
Given partition pruning information for each scan operator of a QueryPlan, we
can evaluate a partition pruning predicate against statement's execution
context to prune partitions that modify operations won't touch.
1. Traverse fragment tree to analyze inputs of DML operations:
- If Modify operation accepts Scan operation as an input (UPDATE), we do not
need to do anything when both operations are collocated and this case is
covered by https://issues.apache.org/jira/browse/IGNITE-21279).
- For operations that accept INSERT/ MERGE, we need to consider values of
colocation key columns of both Value and Projection operators, since SQL's
VALUES accepts DEFAULT expression.
2. Use affinity function and statement's execution context to evaluate
partition pruning predicates for each scan operator, so enlist is only called
for partitions that should be scanned/modified.
After this issue is resolved, partition pruning should work for INSERT, UPDATE,
MERGE, and DELETE statements.
> Sql. Partition pruning. Integrate static partition pruning into MODIFY
> statements execution pipeline.
> -
>
> Key: IGNITE-21281
> URL: https://issues.apache.org/jira/browse/IGNITE-21281
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> Update PartitionExtractor introduced in
> https://issues.apache.org/jira/browse/IGNITE-21277 to compile pruning
> metadata for DML operations.
> In order to that we need to extract values of colocation key columns from
> input operators to ModifyNodes:
> - For operations that do accept scan operation (e.g. plain INSERT), such
> information is included in Values and Projection operators (to get values for
> DEFAULT expression).
> - For that accept scan operation, we should use pruning metadata provided by
> a scan operator.
> *Some examples*
> Plain insert:
> {code:java}
> INSERT INTO t (colo_col1, colo_col2) VALUES (1, 2), (3, 4)
> Partition pruning metadata: t = [ (col_c1 = 1, col_c2 = 2) || (col_c1 = 3,
> col_c2 = 4)]
> {code}
> Plain update
> {code:java}
> UPDATE t SET col = 100 WHERE pk = 42
> Partition pruning metadata: t = [ (pk = 42) ] // Uses metadata provided by a
> scan operation
> {code}
> Delete
> {code:java}
> DELETE FROM t WHERE pk = 42
> Partition pruning metadata: t = [ (pk = 42) ] // Uses metadata provided by a
> scan operation
> {code}
> After this issue is resolved, partition pruning should work for INSERT,
> UPDATE, MERGE, and DELETE statements.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21281) Sql. Partition pruning. Integrate static partition pruning into MODIFY statements execution pipeline.
[ https://issues.apache.org/jira/browse/IGNITE-21281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-21281: --- Description: Given partition pruning information for each scan operator of a QueryPlan, we can evaluate a partition pruning predicate against statement's execution context to prune partitions that modify operations won't touch. 1. Traverse fragment tree to analyze inputs of DML operations: - If Modify operation accepts Scan operation as an input (UPDATE), we do not need to do anything when both operations are collocated and this case is covered by https://issues.apache.org/jira/browse/IGNITE-21279). - For operations that accept INSERT/ MERGE, we need to consider values of colocation key columns of both Value and Projection operators, since SQL's VALUES accepts DEFAULT expression. 2. Use affinity function and statement's execution context to evaluate partition pruning predicates for each scan operator, so enlist is only called for partitions that should be scanned/modified. After this issue is resolved, partition pruning should work for INSERT, UPDATE, MERGE, and DELETE statements. was: Given partition pruning information for each scan operator of a QueryPlan, we can evaluate a partition pruning predicate against statement's execution context to prune partitions that modify operations won't touch. 1. Traverse fragment tree to analyze inputs of DML operations: - If Modify operation accepts Scan operation as an input (UPDATE), we do not need to do anything when both operations are collocated and this case is covered by https://issues.apache.org/jira/browse/IGNITE-21279). - For operations that accept INSERT/ MERGE, we need to consider values of colocation key columns of both Value and Projection operators, since SQL's VALUES accepts DEFAULT expression. 2. Use affinity function and statement's execution context to evaluate partition pruning predicates for each scan operator, so enlist is only called for partitions that should be scanned/modified. After this issue is resolved, partition pruning should work for INSERT, UPDATE, MERGE, and DELETE statements. > Sql. Partition pruning. Integrate static partition pruning into MODIFY > statements execution pipeline. > - > > Key: IGNITE-21281 > URL: https://issues.apache.org/jira/browse/IGNITE-21281 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta2 >Reporter: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > > Given partition pruning information for each scan operator of a QueryPlan, we > can evaluate a partition pruning predicate against statement's execution > context to prune partitions that modify operations won't touch. > 1. Traverse fragment tree to analyze inputs of DML operations: > - If Modify operation accepts Scan operation as an input (UPDATE), we do > not need to do anything when both operations are collocated and this case is > covered by https://issues.apache.org/jira/browse/IGNITE-21279). > - For operations that accept INSERT/ MERGE, we need to consider values of > colocation key columns of both Value and Projection operators, since SQL's > VALUES accepts DEFAULT expression. > 2. Use affinity function and statement's execution context to evaluate > partition pruning predicates for each scan operator, so enlist is only called > for partitions that should be scanned/modified. > After this issue is resolved, partition pruning should work for INSERT, > UPDATE, MERGE, and DELETE statements. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21281) Sql. Partition pruning. Integrate static partition pruning into MODIFY statements execution pipeline.
[ https://issues.apache.org/jira/browse/IGNITE-21281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-21281: -- Epic Link: IGNITE-21312 > Sql. Partition pruning. Integrate static partition pruning into MODIFY > statements execution pipeline. > - > > Key: IGNITE-21281 > URL: https://issues.apache.org/jira/browse/IGNITE-21281 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta2 >Reporter: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > > Given partition pruning information for each scan operator of a QueryPlan, we > can evaluate a partition pruning predicate against statement's execution > context to prune partitions that modify operations won't touch. > 1. Traverse fragment tree to analyze inputs of DML operations: > - If Modify operation accepts Scan operation as an input (UPDATE), we do > not need to do anything when both operations are collocated and this case is > covered by https://issues.apache.org/jira/browse/IGNITE-21279). > - For operations that accept INSERT/ MERGE, we need to consider values of > colocation key columns of both Value and Projection operators, since SQL's > VALUES accepts DEFAULT expression. > 2. Use affinity function and statement's execution context to evaluate > partition pruning predicates for each scan operator, so enlist is only called > for partitions that should be scanned/modified. > After this issue is resolved, partition pruning should work for INSERT, > UPDATE, MERGE, and DELETE statements. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21281) Sql. Partition pruning. Integrate static partition pruning into MODIFY statements execution pipeline.
[ https://issues.apache.org/jira/browse/IGNITE-21281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-21281: -- Description: Given partition pruning information for each scan operator of a QueryPlan, we can evaluate a partition pruning predicate against statement's execution context to prune partitions that modify operations won't touch. 1. Traverse fragment tree to analyze inputs of DML operations: - If Modify operation accepts Scan operation as an input (UPDATE), we do not need to do anything when both operations are collocated and this case is covered by https://issues.apache.org/jira/browse/IGNITE-21279). - For operations that accept INSERT/ MERGE, we need to consider values of colocation key columns of both Value and Projection operators, since SQL's VALUES accepts DEFAULT expression. 2. Use affinity function and statement's execution context to evaluate partition pruning predicates for each scan operator, so enlist is only called for partitions that should be scanned/modified. After this issue is resolved, partition pruning should work for INSERT, UPDATE, MERGE, and DELETE statements. was: Given partition pruning information for each scan operator of a QueryPlan, we can evaluate a partition pruning predicate against statement's execution context to prune partitions that modify operations won't touch. 1. Traverse fragment tree to analyze inputs of DML operations: - If Modify operation accepts Scan operation as an input, we do not need to do anything - since both operations are collocated and this case is covered by https://issues.apache.org/jira/browse/IGNITE-21279). - For operations that accept Values, we need to consider values of colocation key columns of both Value and Projection operators, since SQL's VALUES accepts DEFAULT expression. 2. Use affinity function and statement's execution context to evaluate partition pruning predicates for each scan operator, so enlist is only called for partitions that should be scanned/modified. After this issue is resolved, partition pruning should work for INSERT, UPDATE, MERGE, and DELETE statements. > Sql. Partition pruning. Integrate static partition pruning into MODIFY > statements execution pipeline. > - > > Key: IGNITE-21281 > URL: https://issues.apache.org/jira/browse/IGNITE-21281 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta2 >Reporter: Maksim Zhuravkov >Priority: Major > > Given partition pruning information for each scan operator of a QueryPlan, we > can evaluate a partition pruning predicate against statement's execution > context to prune partitions that modify operations won't touch. > 1. Traverse fragment tree to analyze inputs of DML operations: > - If Modify operation accepts Scan operation as an input (UPDATE), we do > not need to do anything when both operations are collocated and this case is > covered by https://issues.apache.org/jira/browse/IGNITE-21279). > - For operations that accept INSERT/ MERGE, we need to consider values of > colocation key columns of both Value and Projection operators, since SQL's > VALUES accepts DEFAULT expression. > 2. Use affinity function and statement's execution context to evaluate > partition pruning predicates for each scan operator, so enlist is only called > for partitions that should be scanned/modified. > After this issue is resolved, partition pruning should work for INSERT, > UPDATE, MERGE, and DELETE statements. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21281) Sql. Partition pruning. Integrate static partition pruning into MODIFY statements execution pipeline.
[ https://issues.apache.org/jira/browse/IGNITE-21281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-21281: -- Labels: ignite-3 (was: ) > Sql. Partition pruning. Integrate static partition pruning into MODIFY > statements execution pipeline. > - > > Key: IGNITE-21281 > URL: https://issues.apache.org/jira/browse/IGNITE-21281 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta2 >Reporter: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > > Given partition pruning information for each scan operator of a QueryPlan, we > can evaluate a partition pruning predicate against statement's execution > context to prune partitions that modify operations won't touch. > 1. Traverse fragment tree to analyze inputs of DML operations: > - If Modify operation accepts Scan operation as an input (UPDATE), we do > not need to do anything when both operations are collocated and this case is > covered by https://issues.apache.org/jira/browse/IGNITE-21279). > - For operations that accept INSERT/ MERGE, we need to consider values of > colocation key columns of both Value and Projection operators, since SQL's > VALUES accepts DEFAULT expression. > 2. Use affinity function and statement's execution context to evaluate > partition pruning predicates for each scan operator, so enlist is only called > for partitions that should be scanned/modified. > After this issue is resolved, partition pruning should work for INSERT, > UPDATE, MERGE, and DELETE statements. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21281) Sql. Partition pruning. Integrate static partition pruning into MODIFY statements execution pipeline.
[ https://issues.apache.org/jira/browse/IGNITE-21281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-21281: -- Description: Given partition pruning information for each scan operator of a QueryPlan, we can evaluate a partition pruning predicate against statement's execution context to prune partitions that modify operations won't touch. 1. Traverse fragment tree to analyze inputs of DML operations: - If Modify operation accepts Scan operation as an input, we do not need to do anything - since both operations are collocated and this case is covered by https://issues.apache.org/jira/browse/IGNITE-21279). - For operations that accept Values, we need to consider values of colocation key columns of both Value and Projection operators, since SQL's VALUES accepts DEFAULT expression. 2. Use affinity function and statement's execution context to evaluate partition pruning predicates for each scan operator, so enlist is only called for partitions that should be scanned/modified. After this issue is resolved, partition pruning should work for INSERT, UPDATE, MERGE, and DELETE statements. was: Given partition pruning information for each scan operator of a QueryPlan, we can evaluate a partition pruning predicate against statement's execution context to prune partitions that modify operations won't touch. 1. Traverse fragment tree to analyze inputs of DML operations: - If Modify operation accepts Scan operation as an input, we do not need to do anything - since both operations are collocated and this case is covered by https://issues.apache.org/jira/browse/IGNITE-21279). - For operations that accept Values, we need to consider both Value and Projection operators, since SQL's VALUES accepts DEFAULT expression. 2. Use affinity function and statement's execution context to evaluate partition pruning predicates for each scan operator, so enlist is only called for partitions that should be scanned/modified. After this issue is resolved, partition pruning should work for INSERT, UPDATE, MERGE, and DELETE statements. > Sql. Partition pruning. Integrate static partition pruning into MODIFY > statements execution pipeline. > - > > Key: IGNITE-21281 > URL: https://issues.apache.org/jira/browse/IGNITE-21281 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta2 >Reporter: Maksim Zhuravkov >Priority: Major > > Given partition pruning information for each scan operator of a QueryPlan, we > can evaluate a partition pruning predicate against statement's execution > context to prune partitions that modify operations won't touch. > 1. Traverse fragment tree to analyze inputs of DML operations: > - If Modify operation accepts Scan operation as an input, we do not need to > do anything - since both operations are collocated and this case is covered > by https://issues.apache.org/jira/browse/IGNITE-21279). > - For operations that accept Values, we need to consider values of > colocation key columns of both Value and Projection operators, since SQL's > VALUES accepts DEFAULT expression. > 2. Use affinity function and statement's execution context to evaluate > partition pruning predicates for each scan operator, so enlist is only called > for partitions that should be scanned/modified. > After this issue is resolved, partition pruning should work for INSERT, > UPDATE, MERGE, and DELETE statements. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21281) Sql. Partition pruning. Integrate static partition pruning into MODIFY statements execution pipeline.
[ https://issues.apache.org/jira/browse/IGNITE-21281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-21281: -- Description: Given partition pruning information for each scan operator of a QueryPlan, we can evaluate a partition pruning predicate against statement's execution context to prune partitions that modify operations won't touch. 1. Traverse fragment tree to analyze inputs of DML operations: - If Modify operation accepts Scan operation as an input, we do not need to do anything - since both operations are collocated and this case is coverted by X). - For operations that accept Values, we need to consider both Value and Projection operators, since SQL's VALUES accepts DEFAULT expression. 2. Use affinity function and statement's execution context to evaluate partition pruning predicates for each scan operator, so enlist is only called for partitions that should be scanned/modified. After this issue is resolved, partition pruning should work for INSERT, UPDATE, MERGE, and DELETE statements. was: Given partition pruning information for each scan operator of a QueryPlan, we can evaluate a partition pruning predicate against statement's execution context to prune partitions that modify operations won't touch. 1. Traverse fragment tree to analyze inputs of DML operations: - If Modify operation accepts Scan operation as an input, we do not need to do anything - since both operations are collocated and this case is coverted by X). - For operations that accept Values, we need to consider both Value and Projection operators, since SQL's VALUES accepts DEFAULT expression. 2. Use affinity function and statement's execution context to evaluate partition pruning predicates for each scan operator, so enlist is only called for partitions that should be scanned/modified. After this issue is resolved, partition pruning should work for INSERT, UPDATE, MERGE, and DELETE statements. > Sql. Partition pruning. Integrate static partition pruning into MODIFY > statements execution pipeline. > - > > Key: IGNITE-21281 > URL: https://issues.apache.org/jira/browse/IGNITE-21281 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta2 >Reporter: Maksim Zhuravkov >Priority: Major > > Given partition pruning information for each scan operator of a QueryPlan, we > can evaluate a partition pruning predicate against statement's execution > context to prune partitions that modify operations won't touch. > 1. Traverse fragment tree to analyze inputs of DML operations: > - If Modify operation accepts Scan operation as an input, we do not need to > do anything - since both operations are collocated and this case is coverted > by X). > - For operations that accept Values, we need to consider both Value and > Projection operators, since SQL's VALUES accepts DEFAULT expression. > 2. Use affinity function and statement's execution context to evaluate > partition pruning predicates for each scan operator, so enlist is only called > for partitions that should be scanned/modified. > After this issue is resolved, partition pruning should work for INSERT, > UPDATE, MERGE, and DELETE statements. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21281) Sql. Partition pruning. Integrate static partition pruning into MODIFY statements execution pipeline.
[ https://issues.apache.org/jira/browse/IGNITE-21281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-21281: -- Description: Given partition pruning information for each scan operator of a QueryPlan, we can evaluate a partition pruning predicate against statement's execution context to prune partitions that modify operations won't touch. 1. Traverse fragment tree to analyze inputs of DML operations: - If Modify operation accepts Scan operation as an input, we do not need to do anything - since both operations are collocated and this case is covered by https://issues.apache.org/jira/browse/IGNITE-21279). - For operations that accept Values, we need to consider both Value and Projection operators, since SQL's VALUES accepts DEFAULT expression. 2. Use affinity function and statement's execution context to evaluate partition pruning predicates for each scan operator, so enlist is only called for partitions that should be scanned/modified. After this issue is resolved, partition pruning should work for INSERT, UPDATE, MERGE, and DELETE statements. was: Given partition pruning information for each scan operator of a QueryPlan, we can evaluate a partition pruning predicate against statement's execution context to prune partitions that modify operations won't touch. 1. Traverse fragment tree to analyze inputs of DML operations: - If Modify operation accepts Scan operation as an input, we do not need to do anything - since both operations are collocated and this case is coverted by X). - For operations that accept Values, we need to consider both Value and Projection operators, since SQL's VALUES accepts DEFAULT expression. 2. Use affinity function and statement's execution context to evaluate partition pruning predicates for each scan operator, so enlist is only called for partitions that should be scanned/modified. After this issue is resolved, partition pruning should work for INSERT, UPDATE, MERGE, and DELETE statements. > Sql. Partition pruning. Integrate static partition pruning into MODIFY > statements execution pipeline. > - > > Key: IGNITE-21281 > URL: https://issues.apache.org/jira/browse/IGNITE-21281 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta2 >Reporter: Maksim Zhuravkov >Priority: Major > > Given partition pruning information for each scan operator of a QueryPlan, we > can evaluate a partition pruning predicate against statement's execution > context to prune partitions that modify operations won't touch. > 1. Traverse fragment tree to analyze inputs of DML operations: > - If Modify operation accepts Scan operation as an input, we do not need to > do anything - since both operations are collocated and this case is covered > by https://issues.apache.org/jira/browse/IGNITE-21279). > - For operations that accept Values, we need to consider both Value and > Projection operators, since SQL's VALUES accepts DEFAULT expression. > 2. Use affinity function and statement's execution context to evaluate > partition pruning predicates for each scan operator, so enlist is only called > for partitions that should be scanned/modified. > After this issue is resolved, partition pruning should work for INSERT, > UPDATE, MERGE, and DELETE statements. -- This message was sent by Atlassian Jira (v8.20.10#820010)
