You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Konstantin Orlov (Jira)" <ji...@apache.org> on 2025/01/20 09:00:00 UTC
[jira] [Updated] (IGNITE-24257) Sql. Partition Pruning is not working for UPDATE when target and source is same table
[ https://issues.apache.org/jira/browse/IGNITE-24257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Konstantin Orlov updated IGNITE-24257:
--------------------------------------
Description:
Take a look at statements below:
{code}
CREATE TABLE my_table (id INT PRIMARY KEY, val INT);
UPDATE my_table SET val = val * 2 WHERE id = ?;
{code}
Even though DML touches exactly one partition at a time, leaf fragment (containing {{TableModify(IndexScan)}}) is sent to all the nodes from zone, while it's supposed to be sent only on a node hosting partition in question. Also, all partitions are enlisted into transaction, making transaction finalization step too heavy.
Besides, partition pruning metadata, while being constant, is derived on every execution.
All this screws up performance of DML, even such simple ones, making execution time dependent on number of partitions.
was:
Take a look at statements below:
{code}
CREATE TABLE my_table (id INT PRIMARY KEY, val INT);
UPDATE my_table SET val = val * 2 WHERE id = ?;
{code}
Even though DML touches exactly one partition at a time, leaf fragment (containing {{TableModify(IndexScan)}}) is sent on all the nodes from zone, while it's supposed to be sent only on a node hosting partition in question. Also, all partitions are enlisted into transaction, making transaction finalization step too heavy.
Besides, partition pruning metadata, while being constant, is derived on every execution.
All this screws up performance of DML, even such simple ones, making execution time dependent on number of partitions.
> Sql. Partition Pruning is not working for UPDATE when target and source is same table
> -------------------------------------------------------------------------------------
>
> Key: IGNITE-24257
> URL: https://issues.apache.org/jira/browse/IGNITE-24257
> Project: Ignite
> Issue Type: Bug
> Components: sql
> Reporter: Konstantin Orlov
> Assignee: Konstantin Orlov
> Priority: Major
> Labels: ignite-3
>
> Take a look at statements below:
> {code}
> CREATE TABLE my_table (id INT PRIMARY KEY, val INT);
> UPDATE my_table SET val = val * 2 WHERE id = ?;
> {code}
> Even though DML touches exactly one partition at a time, leaf fragment (containing {{TableModify(IndexScan)}}) is sent to all the nodes from zone, while it's supposed to be sent only on a node hosting partition in question. Also, all partitions are enlisted into transaction, making transaction finalization step too heavy.
> Besides, partition pruning metadata, while being constant, is derived on every execution.
> All this screws up performance of DML, even such simple ones, making execution time dependent on number of partitions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)