[jira] [Commented] (TRAFODION-2568) bypass the operator work if the predicate is FALSE

2017-04-06 Thread Suresh Subbiah (JIRA) 

[ 
https://issues.apache.org/jira/browse/TRAFODION-2568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15960243#comment-15960243
 ] 

Suresh Subbiah commented on TRAFODION-2568:
---

This is what we get with a fix. The base table access and index access case go 
through different methods.Notice how begin and end keys are reversed.

-- Base table access
create table test1 (a int not null primary key, b int) salt using 2 partitions ;
insert into test1 values (1,1),(2,2),(3,3),(4,4) ;
prepare s2 from select * from test1 where a > 0 and 1 = 0;
explain s2 ;
set statistics on ;
execute s2 ;

TRAFODION_SCAN   SEQ_NO 1NO CHILDREN
TABLE_NAME ... TEST1
REQUESTS_IN .. 1
ROWS_OUT . 1
EST_OPER_COST  0.01
EST_TOTAL_COST ... 0.01
DESCRIPTION
  max_card_est ... 0
  fragment_id  0
  parent_frag  (none)
  fragment_type .. master
  scan_type .. subset scan of table TRAFODION.SEABASE.TEST1
  object_type  Trafodion
  columns  all
  begin_keys(incl) ... 4294967295,??
  end_keys(incl) . 0,
  cache_size ... 100
  probes . 1
  rows_accessed  100
  column_retrieved ... #1:1
  key_columns  _SALT_, A
  executor_predicates  0.

--- SQL operation complete.

--- 0 row(s) selected.

Start Time 2017/04/07 04:00:53.393346
End Time   2017/04/07 04:00:53.409268
Elapsed Time  00:00:00.015922
Compile Time  00:00:04.653079
Execution Time00:00:00.015922


Table Name RecordsRecords  Hdfs   Hdfs I/OHdfs 
Access
  Accessed   Used  I/Os  Bytes 
Time(usec)
TRAFODION.SEABASE.TEST1
 0  0 2  0  
13600


-- Index access
create table tbl (
k1 int not null,
k2 int not null,
ts timestamp not null,
a char(10),
b varchar(30),
c largeint,
primary key (k1,k2,ts))
salt using 2 partitions 
division by (date_trunc('MONTH', ts)) ;

upsert using load into tbl
select num/1000, num, DATEADD(SECOND,-num,CURRENT_TIMESTAMP),cast(num as 
char(10)), cast(num as varchar(30)), num*1000
from (select 10*x10+1*x1+1000*x1000+100*x100+10*x10+x1 as num
from (values (0)) seed(c)
transpose 0,1,2,3,4,5,6,7,8,9 as x1
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 x100
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 x1
transpose 0,1,2,3,4,5,6,7,8,9 as x10
) T
;

create index tbl_idx1_b on tbl(b) salt like table;
prepare s1 from select * from tbl where b > 5 and 1 = 0 ;

>>explain options 'f' s1 ;

LC   RC   OP   OPERATOR  OPT   DESCRIPTION   CARD
         -

5.6root  1.00E+000
245nested_join   1.00E+000
3.4probe_cache   1.00E+000
..3trafodion_vsbb_scan TBL   1.00E+000
1.2esp_exchange1:2(hash2)1.00E+000
..1trafodion_index_scanTBL_IDX1_B1.00E+000

--- SQL operation complete.


TRAFODION_INDEX_SCAN ==  SEQ_NO 1NO CHILDREN
TABLE_NAME ... TBL
REQUESTS_IN .. 1
ROWS_OUT . 1
EST_OPER_COST  1.03
EST_TOTAL_COST ... 1.03
DESCRIPTION
  max_card_est ... 0
  fragment_id  2
  parent_frag  0
  fragment_type .. esp
  scan_type .. full scan of index TRAFODION.SEABASE.TBL_IDX1_B(TRAF
 ODION.SEABASE.TBL)
  object_type  Trafodion
  cache_size  10,000
  probes . 1
  rows_accessed .. 1e+06
  column_retrieved ... #1:1
  key_columns  TRAFODION.SEABASE.TBL_IDX1_B._SALT_,
 TRAFODION.SEABASE.TBL_IDX1_B.B,
 TRAFODION.SEABASE.TBL_IDX1_B._DIVISION_1_,
 TRAFODION.SEABASE.TBL_IDX1_B.K1,
 TRAFODION.SEABASE.TBL_IDX1_B.K2,
 TRAFODION.SEABASE.TBL_IDX1_B.TS
  executor_predicates  0. and (TRAFODION.SEABASE.TBL_IDX1_B._SALT_ >=
 (\:_sys_HostVarLoHashPart Hash2Distrib 2)) and
 (TRAFODION.SEABASE.TBL_IDX1_B._SALT_ <=
 (\:_sys_HostVarHiHashPart Hash2Distrib 2))
  begin_key .. (TRAFODION.SEABASE.TBL_IDX1_B._SALT_ = ),
 (TRAFODION.SEABASE.TBL_IDX1_B.B = ''),

[jira] [Commented] (TRAFODION-2574) Index plan not chosen for UPDATE when WHERE clause and SET clause are on the same index column

2017-04-06 Thread Suresh Subbiah (JIRA) 

[ 
https://issues.apache.org/jira/browse/TRAFODION-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15960188#comment-15960188
 ] 

Suresh Subbiah commented on TRAFODION-2574:
---

Here is the plan we now get for these four statements (with a fix)

>>control query shape nested_join(nested_join(cut,cut),cut);

--- SQL operation complete.
>>prepare s1 from update tbl set b = 'haha' where b = 'sad' ;

>>explain options 'f' s1 ;

LC   RC   OP   OPERATOR  OPT   DESCRIPTION   CARD
         -

14   .15   rootx 4.00E+000
613   14   nested_join   4.00E+000
912   13   merge_union   4.00E+000
10   11   12   blocked_union 2.00E+000
..11   trafodion_insertTBL_IDX1_B1.00E+000
..10   trafodion_vsbb_deletTBL_IDX1_B1.00E+000
789blocked_union 2.00E+000
..8trafodion_insertTBL_IDX1_AB   1.00E+000
..7trafodion_vsbb_deletTBL_IDX1_AB   1.00E+000
456nested_join   1.00E+000
..5trafodion_updateTBL   1.00E+000
134nested_join   1.00E+000
2.3probe_cache   1.00E+000
..2trafodion_vsbb_scan TBL   1.00E+000
..1trafodion_index_scanTBL_IDX1_B1.00E+000

--- SQL operation complete.


-- should choose tbl_idx1_ab
>>prepare s2 from update tbl set a = 'haha' where a = 'sad' ;

--- SQL command prepared.

>>explain options 'f' s2 ;

LC   RC   OP   OPERATOR  OPT   DESCRIPTION   CARD
         -

7.8rootx 2.00E+000
367nested_join   2.00E+000
456blocked_union 2.00E+000
..5trafodion_insertTBL_IDX1_AB   1.00E+000
..4trafodion_vsbb_deletTBL_IDX1_AB   1.00E+000
123nested_join   1.00E+000
..2trafodion_updateTBL   1.00E+000
..1trafodion_index_scanTBL_IDX1_AB   1.00E+000

--- SQL operation complete.
>>prepare s3 from update tbl set b = 'haha' where b > 'sad' ;

--- SQL command prepared.
>>explain options 'f' s3 ;

LC   RC   OP   OPERATOR  OPT   DESCRIPTION   CARD
         -

15   .16   rootx 4.00E+000
714   15   nested_join   4.00E+000
10   13   14   merge_union   4.00E+000
11   12   13   blocked_union 2.00E+000
..12   trafodion_insertTBL_IDX1_B1.00E+000
..11   trafodion_vsbb_deletTBL_IDX1_B1.00E+000
8910   blocked_union 2.00E+000
..9trafodion_insertTBL_IDX1_AB   1.00E+000
..8trafodion_vsbb_deletTBL_IDX1_AB   1.00E+000
567nested_join   1.00E+000
..6trafodion_updateTBL   1.00E+000
4.5sort  1.00E+000
134nested_join   1.00E+000
2.3probe_cache   1.00E+000
..2trafodion_vsbb_scan TBL   1.00E+000
..1trafodion_index_scanTBL_IDX1_B1.00E+000

--- SQL operation complete.
>>prepare s4 from update tbl set a = 'haha' where a > 'sad' ;

--- SQL command prepared.
>>explain options 'f' s4 ;

LC   RC   OP   OPERATOR  OPT   DESCRIPTION   CARD
         -

8.9rootx 2.00E+000
478nested_join   2.00E+000
567blocked_union 2.00E+000
..6trafodion_insertTBL_IDX1_AB   1.00E+000
..5

[jira] [Resolved] (TRAFODION-2576) Incremental UPDATE STATS fails on long varchar values

2017-04-06 Thread David Wayne Birdsall (JIRA) 

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

David Wayne Birdsall resolved TRAFODION-2576.
-
   Resolution: Fixed
Fix Version/s: 2.2-incubating

> Incremental UPDATE STATS fails on long varchar values
> -
>
> Key: TRAFODION-2576
> URL: https://issues.apache.org/jira/browse/TRAFODION-2576
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-cmp
> Environment: All
>Reporter: David Wayne Birdsall
>Assignee: David Wayne Birdsall
> Fix For: 2.2-incubating
>
>
> The following test script demonstrates the problem:
> -- This script creates a table with varchar values longer than 256 characters.
> -- It tnen demonstrates issues with incremental stats on such values.
> ?section setup
> drop table if exists testbigcol;
> create table testbigcol
>   ( a int not null,
> b varchar(500),
> primary key (a) )
> salt using 4 partitions;
> insert into testbigcol values (1,'axq'),(2,'bxw');
> insert into testbigcol select x.a + 2 * y.a, x.b || y.b from testbigcol x 
> cross join testbigcol y;
> insert into testbigcol select x.a + 6 * y.a, x.b || y.b from testbigcol x 
> cross join testbigcol y;
> insert into testbigcol select x.a + 42 * y.a, x.b || y.b from testbigcol x 
> cross join testbigcol y;
> --  0 1 2 3 4 
> 5
> --  
> 012345678901234567890123456789012345678901234567890123
> update testbigcol set b = b || ' and now for something completely different 
> 0123456789'
>   where mod(a,2) = 1;
> update testbigcol set b = b || ' that was fun, and now for something 
> completely different 0123456789'
>   where mod(a,3) = 1;
> update testbigcol set b = b || ' and then there was a great hue and cry and 
> now for something completely different 0123456789'
>   where mod(a,5) = 1;
> update testbigcol set b = b || ' and we can do all sorts of things to make 
> these strings longer, and now for something completely different 0123456789'
>   where mod(a,7) = 1;
> ?section testit
> update statistics for table testbigcol on every column sample random 100 
> percent persistent;
> showstats for table testbigcol on existing columns detail;
> update testbigcol set b = 'c' || b where a > 1700;
> update statistics for table testbigcol on existing columns incremental where 
> a > 1700;
> showstats for table testbigcol on existing columns detail;
> When run, the last UPDATE STATISTICS command fails as follows:
> >>update statistics for table testbigcol on existing columns incremental 
> >>where a > 1700;
> *** ERROR[9200] UPDATE STATISTICS for table TRAFODION.SEABASE.TESTBIGCOL 
> encountered an error (8402) from statement IUS data set I creation.
> *** ERROR[8402] A string overflow occurred during the evaluation of a 
> character expression. Conversion of Source Type:VARCHAR(REC_BYTE_V_ASCII,290 
> BYTES,ISO88591) Source Value:caxqbxwbxwaxqaxqbxwbxwbxw and now for something 
> completely different 0123456789 and then there was a great hue and cry and 
> now for something completely different 0123456789 and we can do all sorts of 
> to Target Type:VARCHAR(REC_BYTE_V_ASCII,256 BYTES,ISO88591).
> --- SQL operation failed with errors.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (TRAFODION-2576) Incremental UPDATE STATS fails on long varchar values

2017-04-06 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/TRAFODION-2576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15959950#comment-15959950
 ] 

ASF GitHub Bot commented on TRAFODION-2576:
---

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-trafodion/pull/1046


> Incremental UPDATE STATS fails on long varchar values
> -
>
> Key: TRAFODION-2576
> URL: https://issues.apache.org/jira/browse/TRAFODION-2576
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-cmp
> Environment: All
>Reporter: David Wayne Birdsall
>Assignee: David Wayne Birdsall
>
> The following test script demonstrates the problem:
> -- This script creates a table with varchar values longer than 256 characters.
> -- It tnen demonstrates issues with incremental stats on such values.
> ?section setup
> drop table if exists testbigcol;
> create table testbigcol
>   ( a int not null,
> b varchar(500),
> primary key (a) )
> salt using 4 partitions;
> insert into testbigcol values (1,'axq'),(2,'bxw');
> insert into testbigcol select x.a + 2 * y.a, x.b || y.b from testbigcol x 
> cross join testbigcol y;
> insert into testbigcol select x.a + 6 * y.a, x.b || y.b from testbigcol x 
> cross join testbigcol y;
> insert into testbigcol select x.a + 42 * y.a, x.b || y.b from testbigcol x 
> cross join testbigcol y;
> --  0 1 2 3 4 
> 5
> --  
> 012345678901234567890123456789012345678901234567890123
> update testbigcol set b = b || ' and now for something completely different 
> 0123456789'
>   where mod(a,2) = 1;
> update testbigcol set b = b || ' that was fun, and now for something 
> completely different 0123456789'
>   where mod(a,3) = 1;
> update testbigcol set b = b || ' and then there was a great hue and cry and 
> now for something completely different 0123456789'
>   where mod(a,5) = 1;
> update testbigcol set b = b || ' and we can do all sorts of things to make 
> these strings longer, and now for something completely different 0123456789'
>   where mod(a,7) = 1;
> ?section testit
> update statistics for table testbigcol on every column sample random 100 
> percent persistent;
> showstats for table testbigcol on existing columns detail;
> update testbigcol set b = 'c' || b where a > 1700;
> update statistics for table testbigcol on existing columns incremental where 
> a > 1700;
> showstats for table testbigcol on existing columns detail;
> When run, the last UPDATE STATISTICS command fails as follows:
> >>update statistics for table testbigcol on existing columns incremental 
> >>where a > 1700;
> *** ERROR[9200] UPDATE STATISTICS for table TRAFODION.SEABASE.TESTBIGCOL 
> encountered an error (8402) from statement IUS data set I creation.
> *** ERROR[8402] A string overflow occurred during the evaluation of a 
> character expression. Conversion of Source Type:VARCHAR(REC_BYTE_V_ASCII,290 
> BYTES,ISO88591) Source Value:caxqbxwbxwaxqaxqbxwbxwbxw and now for something 
> completely different 0123456789 and then there was a great hue and cry and 
> now for something completely different 0123456789 and we can do all sorts of 
> to Target Type:VARCHAR(REC_BYTE_V_ASCII,256 BYTES,ISO88591).
> --- SQL operation failed with errors.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (TRAFODION-2579) installers should allow multiple ldap hosts and ldap UID lines

2017-04-06 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/TRAFODION-2579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15959876#comment-15959876
 ] 

ASF GitHub Bot commented on TRAFODION-2579:
---

GitHub user svarnau opened a pull request:

https://github.com/apache/incubator-trafodion/pull/1050

[TRAFODION-2579] Allow multiple LDAP values in ambari-installer

Also updates service number to match release number on master branch.
Common services remain as 2.1, since they work for 2.1+ releases.

This version of ambari installer specifies trafodion 2.2 for all
three HDP stacks.  If it becomes incompatible, then we should specify
2.1 for the older stacks.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/svarnau/incubator-trafodion amb2579

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-trafodion/pull/1050.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1050


commit d83c9b170954efdb29aa4dd1e2626f14b00d0635
Author: Steve Varnau 
Date:   2017-04-06T22:07:30Z

[TRAFODION-2579] Allow multiple LDAP values in ambari-installer

Also updates service number to match release number on master branch.
Common services remain as 2.1, since they work for 2.1+ releases.

This version of ambari installer specifies trafodion 2.2 for all
three HDP stacks.  If it becomes incompatible, then we should specify
2.1 for the older stacks.




> installers should allow multiple ldap hosts and ldap UID lines
> --
>
> Key: TRAFODION-2579
> URL: https://issues.apache.org/jira/browse/TRAFODION-2579
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: installer
>Affects Versions: 2.2-incubating
>Reporter: Steve Varnau
>
> Both python and ambari installer seem to limit LDAP configuration.
> Instead of 
>LDAPHostName: host,host2
> the generated config should be:
>LDAPHostName: host
>LDAPHostName: host2
> The same is true of the UniqueIdentifier keyword.  These should be one per 
> line and an identifier string can contain embedded spaces. A better separator 
> would perhaps be semi-colon.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (TRAFODION-2583) Remove deprecated CQD HIVE_MAX_STRING_LENGTH

2017-04-06 Thread David Wayne Birdsall (JIRA) 

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

David Wayne Birdsall updated TRAFODION-2583:

Description: 
Last November in JIRA TRAFODION-2352, we added a CQD 
HIVE_MAX_STRING_LENGTH_IN_BYTES which sets the length of a hive string type for 
Trafodion's purposes. (Hive string types have unlimited length. Trafodion 
treats these as VARCHARs, but they must have a maximum length.) This CQD was 
intended to take the place of HIVE_MAX_STRING_LENGTH, which was not clear about 
the storage unit and therefore error-prone. We left the old CQD in to allow 
folks to make the change in their scripts at their leisure.

The time has come to remove the old CQD.

  was:
Last November in JIRA TRAFODION-2352, we added a CQD 
HIVE_MAX_STRING_LENGTH_IN_BYTES which sets the length of a hive string type for 
Trafodion's purposes. (Hive string types have unlimited length. Trafodion 
treats these as VARCHARs, but they must have a maximum length.) This CQD was 
intended to take the place of HIVE_MAX_STRING_LENGTH, which was not clear about 
the storage unit and therefore error-prone.

The time has come to remove the old CQD.


> Remove deprecated CQD HIVE_MAX_STRING_LENGTH
> 
>
> Key: TRAFODION-2583
> URL: https://issues.apache.org/jira/browse/TRAFODION-2583
> Project: Apache Trafodion
>  Issue Type: Improvement
>  Components: sql-cmp
>Affects Versions: 2.2-incubating
>Reporter: David Wayne Birdsall
>Assignee: David Wayne Birdsall
>
> Last November in JIRA TRAFODION-2352, we added a CQD 
> HIVE_MAX_STRING_LENGTH_IN_BYTES which sets the length of a hive string type 
> for Trafodion's purposes. (Hive string types have unlimited length. Trafodion 
> treats these as VARCHARs, but they must have a maximum length.) This CQD was 
> intended to take the place of HIVE_MAX_STRING_LENGTH, which was not clear 
> about the storage unit and therefore error-prone. We left the old CQD in to 
> allow folks to make the change in their scripts at their leisure.
> The time has come to remove the old CQD.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (TRAFODION-2583) Remove deprecated CQD HIVE_MAX_STRING_LENGTH

2017-04-06 Thread David Wayne Birdsall (JIRA) 
David Wayne Birdsall created TRAFODION-2583:
---

 Summary: Remove deprecated CQD HIVE_MAX_STRING_LENGTH
 Key: TRAFODION-2583
 URL: https://issues.apache.org/jira/browse/TRAFODION-2583
 Project: Apache Trafodion
  Issue Type: Improvement
  Components: sql-cmp
Affects Versions: 2.2-incubating
Reporter: David Wayne Birdsall
Assignee: David Wayne Birdsall


Last November in JIRA TRAFODION-2352, we added a CQD 
HIVE_MAX_STRING_LENGTH_IN_BYTES which sets the length of a hive string type for 
Trafodion's purposes. (Hive string types have unlimited length. Trafodion 
treats these as VARCHARs, but they must have a maximum length.) This CQD was 
intended to take the place of HIVE_MAX_STRING_LENGTH, which was not clear about 
the storage unit and therefore error-prone.

The time has come to remove the old CQD.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (TRAFODION-2577) Ambari installer not setting ZK environment variables

2017-04-06 Thread Steve Varnau (JIRA) 

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

Steve Varnau resolved TRAFODION-2577.
-
   Resolution: Fixed
Fix Version/s: 2.1-incubating

> Ambari installer not setting ZK environment variables
> -
>
> Key: TRAFODION-2577
> URL: https://issues.apache.org/jira/browse/TRAFODION-2577
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: installer
>Affects Versions: 2.1-incubating
>Reporter: Steve Varnau
>Assignee: Steve Varnau
> Fix For: 2.1-incubating
>
>
> Tried it again.  I was able to build Trafodion but not installed it through 
> Ambari installer.
> Trafodion was unable to start:
> 2017-04-04 23:33:42,919, FATAL, MON, Node Number: 0,, PIN: 29309 , Process 
> Name: $MONITOR,,, TID: 29309, Message ID: 101022301, 
> [CMonitor::CreateZookeeperClient], Zookeeper quorum port is not defined!
> As part of installation, two envvars need to be setup:
>   export ZOOKEEPER_NODES
>   export ZOOKEEPER_PORT
> It looks like these envvars are not being setup correctly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (TRAFODION-2577) Ambari installer not setting ZK environment variables

2017-04-06 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/TRAFODION-2577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15959519#comment-15959519
 ] 

ASF GitHub Bot commented on TRAFODION-2577:
---

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-trafodion/pull/1047


> Ambari installer not setting ZK environment variables
> -
>
> Key: TRAFODION-2577
> URL: https://issues.apache.org/jira/browse/TRAFODION-2577
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: installer
>Affects Versions: 2.1-incubating
>Reporter: Steve Varnau
>Assignee: Steve Varnau
>
> Tried it again.  I was able to build Trafodion but not installed it through 
> Ambari installer.
> Trafodion was unable to start:
> 2017-04-04 23:33:42,919, FATAL, MON, Node Number: 0,, PIN: 29309 , Process 
> Name: $MONITOR,,, TID: 29309, Message ID: 101022301, 
> [CMonitor::CreateZookeeperClient], Zookeeper quorum port is not defined!
> As part of installation, two envvars need to be setup:
>   export ZOOKEEPER_NODES
>   export ZOOKEEPER_PORT
> It looks like these envvars are not being setup correctly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (TRAFODION-2576) Incremental UPDATE STATS fails on long varchar values

2017-04-06 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/TRAFODION-2576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15959182#comment-15959182
 ] 

ASF GitHub Bot commented on TRAFODION-2576:
---

Github user DaveBirdsall commented on a diff in the pull request:


https://github.com/apache/incubator-trafodion/pull/1046#discussion_r110201855
  
--- Diff: core/sql/ustat/hs_globals.cpp ---
@@ -1882,6 +1882,55 @@ NABoolean HSColumnStruct::operator==(const 
HSColumnStruct& other) const
 return ( colnum == other.colnum );
   }
 
+//
+// METHOD:  addTruncatedColumnReference()
+//
+// PURPOSE: Generates a column reference or a SUBSTRING
+//  on a column reference which truncates the
+//  column to the maximum length allowed in
+//  UPDATE STATISTICS.
+//
+// INPUT:   'qry' - the SQL query string to append the 
+//  reference to.
+//  'colInfo' - struct containing datatype info
+//  about the column.
+//
+void HSColumnStruct::addTruncatedColumnReference(NAString & qry)
+  {
+HSGlobalsClass *hs_globals = GetHSContext();
+Lng32 maxLengthInBytes = hs_globals->maxCharColumnLengthInBytes;
+bool isOverSized = DFS2REC::isAnyCharacter(datatype) &&
+   (length > maxLengthInBytes);
+if (isOverSized)
+  {
+// Note: The result data type of SUBSTRING is VARCHAR, always.
+// But if the column is CHAR, many places in the ustat code are not
+// expecting a VARCHAR. So, we stick a CAST around it to convert
+// it back to a CHAR in these cases.
+
+NABoolean isFixedChar = DFS2REC::isSQLFixedChar(datatype);
+if (isFixedChar)
+  qry += "CAST(";
+qry += "SUBSTRING(";
+qry += externalColumnName->data();
+qry += " FOR ";
+
+char temp[20];  // big enough for "nn)"
+sprintf(temp,"%d)", maxLengthInBytes / 
CharInfo::maxBytesPerChar(charset));
+qry += temp;
+if (isFixedChar)
+  {
+qry += " AS CHAR(";
+qry += temp;
+qry += ")";
--- End diff --

Thanks for these comments. Your analysis is correct. The code is limiting 
strings to 256 bytes, which for UTF-8 means 64 characters since the longest 
UTF-8 character is 4 bytes long.

By the way, the 256 byte limit is controllable by CQD so a customer or user 
can increase this if they wish. The CQD is USTAT_MAX_CHAR_COL_LENGTH_IN_BYTES.


> Incremental UPDATE STATS fails on long varchar values
> -
>
> Key: TRAFODION-2576
> URL: https://issues.apache.org/jira/browse/TRAFODION-2576
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-cmp
> Environment: All
>Reporter: David Wayne Birdsall
>Assignee: David Wayne Birdsall
>
> The following test script demonstrates the problem:
> -- This script creates a table with varchar values longer than 256 characters.
> -- It tnen demonstrates issues with incremental stats on such values.
> ?section setup
> drop table if exists testbigcol;
> create table testbigcol
>   ( a int not null,
> b varchar(500),
> primary key (a) )
> salt using 4 partitions;
> insert into testbigcol values (1,'axq'),(2,'bxw');
> insert into testbigcol select x.a + 2 * y.a, x.b || y.b from testbigcol x 
> cross join testbigcol y;
> insert into testbigcol select x.a + 6 * y.a, x.b || y.b from testbigcol x 
> cross join testbigcol y;
> insert into testbigcol select x.a + 42 * y.a, x.b || y.b from testbigcol x 
> cross join testbigcol y;
> --  0 1 2 3 4 
> 5
> --  
> 012345678901234567890123456789012345678901234567890123
> update testbigcol set b = b || ' and now for something completely different 
> 0123456789'
>   where mod(a,2) = 1;
> update testbigcol set b = b || ' that was fun, and now for something 
> completely different 0123456789'
>   where mod(a,3) = 1;
> update testbigcol set b = b || ' and then there was a great hue and cry and 
> now for something completely different 0123456789'
>   where mod(a,5) = 1;
> update testbigcol set b = b || ' and we can do all sorts of things to make 
> these strings longer, and now for something completely different 0123456789'
>   where mod(a,7) = 1;
> ?section testit
> update statistics for table testbigcol on every column sample random 100 
> percent persistent;
> showstats for table testbigcol on existing columns detail;
> update testbigcol set b = 'c' || b where a > 1700;
> update statistics for table testbigcol on existing columns incremental where 
> a > 1700;
> showstats

[jira] [Commented] (TRAFODION-2579) installers should allow multiple ldap hosts and ldap UID lines

2017-04-06 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/TRAFODION-2579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15958530#comment-15958530
 ] 

ASF GitHub Bot commented on TRAFODION-2579:
---

GitHub user mkby opened a pull request:

https://github.com/apache/incubator-trafodion/pull/1049

[TRAFODION-2579] installers should allow multiple ldap hosts and ldap UID 
lines

changes for pyinstaller part.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mkby/incubator-trafodion 2579

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-trafodion/pull/1049.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1049


commit 4de192332ef35768f8a86890c6a765b3df692999
Author: Eason 
Date:   2017-04-06T08:24:53Z

[TRAFODION-2579] installers should allow multiple ldap hosts and ldap UID 
lines




> installers should allow multiple ldap hosts and ldap UID lines
> --
>
> Key: TRAFODION-2579
> URL: https://issues.apache.org/jira/browse/TRAFODION-2579
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: installer
>Affects Versions: 2.2-incubating
>Reporter: Steve Varnau
>
> Both python and ambari installer seem to limit LDAP configuration.
> Instead of 
>LDAPHostName: host,host2
> the generated config should be:
>LDAPHostName: host
>LDAPHostName: host2
> The same is true of the UniqueIdentifier keyword.  These should be one per 
> line and an identifier string can contain embedded spaces. A better separator 
> would perhaps be semi-colon.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (TRAFODION-2526) pyinstaller - don't use sudo command in root user during installation

2017-04-06 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/TRAFODION-2526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15958473#comment-15958473
 ] 

ASF GitHub Bot commented on TRAFODION-2526:
---

GitHub user mkby opened a pull request:

https://github.com/apache/incubator-trafodion/pull/1048

[TRAFODION-2526] pyinstaller - don't use sudo command in root user during 
installation

along with some other stability fixes.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mkby/incubator-trafodion 2526

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-trafodion/pull/1048.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1048


commit 34c70d0d3bc7c8d11310719030ddc48768df5c07
Author: Eason 
Date:   2017-04-06T07:29:51Z

[TRAFODION-2526] pyinstaller - don't use sudo command in root user during 
installation




> pyinstaller - don't use sudo command in root user during installation
> -
>
> Key: TRAFODION-2526
> URL: https://issues.apache.org/jira/browse/TRAFODION-2526
> Project: Apache Trafodion
>  Issue Type: Bug
>Reporter: Eason Zhang
>Assignee: Eason Zhang
>
> If runs installer in root user, donnot use 'sudo' command.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)