You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafodion.apache.org by "Sandhya Sundaresan (JIRA)" <ji...@apache.org> on 2015/11/13 22:50:10 UTC
[jira] [Created] (TRAFODION-1625) Trafodion delete on large table
is treated as a unique delete
Sandhya Sundaresan created TRAFODION-1625:
---------------------------------------------
Summary: Trafodion delete on large table is treated as a unique delete
Key: TRAFODION-1625
URL: https://issues.apache.org/jira/browse/TRAFODION-1625
Project: Apache Trafodion
Issue Type: Bug
Components: sql-exe
Affects Versions: 2.0-incubating
Reporter: Sandhya Sundaresan
Assignee: Sandhya Sundaresan
A delete on a 200K large table was treated like a unique delete. This was found when the long operation was not being cancelled when a cancel query was issued. Unique queries are typcially not canceable since they are very short running. This caused regress/executor/TEST106 to fail.
To reproduce :
create table t106a
(uniq int not null,
c10K int ,
c1K int,
c100 int,
c10 int,
c1 int,
primary key (uniq)
)
salt using 4 partitions ;
upsert using load into t106a
select
0 + (100000 * x100000) + (10000 * x10000) + (1000 * x1000) + (100 * x100)
+ (10 * x10) +( 1 * x1),
0 + (1000 * x1000) + (100 * x100) + (10 * x10) + (1 * x1),
0 + (100 * x100) + (10 * x10) + (1 * x1),
0 + (10 * x10) + (1 * x1),
0 + (1 * x1),
0
from (values(1)) as t1
transpose 0,1 as x100000
transpose 0,1,2,3,4,5,6,7,8,9 as x10000
transpose 0,1,2,3,4,5,6,7,8,9 as x1000
transpose 0,1,2,3,4,5,6,7,8,9 as x100
transpose 0,1,2,3,4,5,6,7,8,9 as x10
transpose 0,1,2,3,4,5,6,7,8,9 as x1
;
prepare s2 from delete from t106a;
During the prepare of s2, it is clear from debugger that it is treated as unique.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)