[ 
https://issues.apache.org/jira/browse/IGNITE-27679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vyacheslav Koptilin updated IGNITE-27679:
-----------------------------------------
    Description: 
Take a look at the script below:
{code:java}
CREATE TABLE integers (i INT PRIMARY KEY);
INSERT INTO integers SELECT * FROM TABLE(system_range(1, 1000));
SELECT count(*) FROM integers;
DELETE FROM integers;
{code}
Initially, {{SELECT count(*)}} was not affected by consequent {{DELETE}} 
statement because it was executed in fair RO transaction. But after 
optimization introduced in IGNITE-22829 this invariant was broken as now, if 
aforementioned optimization is applied, the execution follows short path 
avoiding creation of transaction.

  was:
Take a look at script below:
{code}
CREATE TABLE integers (i INT PRIMARY KEY);
INSERT INTO integers SELECT * FROM TABLE(system_range(1, 1000));
SELECT count(*) FROM integers;
DELETE FROM integers;
{code}

Initially, {{SELECT count(*)}} was not affected by consequent {{DELETE}} 
statement because it was executed in fair RO transaction. But after 
optimization introduced in IGNITE-22829 this invariant was broken as now, if 
aforementioned optimization is applied, the execution follows short path 
avoiding creation of transaction.


> Sql. SelectCount plan is affected by consequent DML in script
> -------------------------------------------------------------
>
>                 Key: IGNITE-27679
>                 URL: https://issues.apache.org/jira/browse/IGNITE-27679
>             Project: Ignite
>          Issue Type: Bug
>          Components: sql ai3
>    Affects Versions: 3.1
>            Reporter: Konstantin Orlov
>            Priority: Major
>              Labels: ignite-3
>
> Take a look at the script below:
> {code:java}
> CREATE TABLE integers (i INT PRIMARY KEY);
> INSERT INTO integers SELECT * FROM TABLE(system_range(1, 1000));
> SELECT count(*) FROM integers;
> DELETE FROM integers;
> {code}
> Initially, {{SELECT count(*)}} was not affected by consequent {{DELETE}} 
> statement because it was executed in fair RO transaction. But after 
> optimization introduced in IGNITE-22829 this invariant was broken as now, if 
> aforementioned optimization is applied, the execution follows short path 
> avoiding creation of transaction.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to