[
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)
