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)