You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafodion.apache.org by "Suresh Subbiah (JIRA)" <ji...@apache.org> on 2017/10/19 06:52:00 UTC
[jira] [Resolved] (TRAFODION-2776) Mdam plans with more than one
disjunct sometimes cause either a compiler core or have an incorrect
predicate
[ https://issues.apache.org/jira/browse/TRAFODION-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Suresh Subbiah resolved TRAFODION-2776.
---------------------------------------
Resolution: Fixed
> Mdam plans with more than one disjunct sometimes cause either a compiler core or have an incorrect predicate
> ------------------------------------------------------------------------------------------------------------
>
> Key: TRAFODION-2776
> URL: https://issues.apache.org/jira/browse/TRAFODION-2776
> Project: Apache Trafodion
> Issue Type: Bug
> Components: sql-cmp
> Affects Versions: any
> Reporter: Suresh Subbiah
> Assignee: Suresh Subbiah
> Fix For: 2.3-incubating
>
>
> This query will have several disjuncts, with many of them being incorrect.
> prepare s1 from
> select count(*)
> from dwd_roam_03_cngi_src a
> where a.apnni not in ('CMREAD','IMS')
> and a.start_datetime like '201708%'
> and (a.apnni not in ('CMLAP','CMTDS','CMNET') or (substr(a.msisdn,1,6) not in ('147165','147166','147167','147168','147169')) and substr(a.msisdn,1,5) <> '14744');
> Disjuncts 2-5 are incorrect here as they stop after column 0 (_SALT_).
> mdam_disjunct .......... (START_DATETIME >= '201708') and (START_DATETIME <
> '201709') and (((APNNI < 'CMREAD') or (APNNI >
> 'CMREAD') and (APNNI < 'IMS')) or (APNNI > 'IMS'))
> and (APNNI < 'CMLAP') and (_SALT_ >=
> (\:_sys_HostVarLoHashPart Hash2Distrib 8)) and
> (_SALT_ <= (\:_sys_HostVarHiHashPart Hash2Distrib
> 8))
> mdam_disjunct .......... (_SALT_ >= (\:_sys_HostVarLoHashPart Hash2Distrib
> 8)) and (_SALT_ <= (\:_sys_HostVarHiHashPart
> Hash2Distrib 8))
> mdam_disjunct .......... (_SALT_ >= (\:_sys_HostVarLoHashPart Hash2Distrib
> 8)) and (_SALT_ <= (\:_sys_HostVarHiHashPart
> Hash2Distrib 8))
> mdam_disjunct .......... (_SALT_ >= (\:_sys_HostVarLoHashPart Hash2Distrib
> 8)) and (_SALT_ <= (\:_sys_HostVarHiHashPart
> Hash2Distrib 8))
> mdam_disjunct .......... (_SALT_ >= (\:_sys_HostVarLoHashPart Hash2Distrib
> 8)) and (_SALT_ <= (\:_sys_HostVarHiHashPart
> Hash2Distrib 8))
> The problem also manifests with a core for this related query
> prepare s1 from
> select count(*)
> from dwd_roam_03_cngi_src a
> where a.apnni not in ('CMREAD','IMS')
> and a.start_datetime like '201708%'
> and (a.apnni not in ('CMLAP','CMTDS','CMNET') or (substr(a.msisdn,1,6) not in ('147165','147166')));
> In debug mode we may see a failed assert for both queries due to a DCMPASSERT in code.
> This shape may be needed to see the problem
> control query shape expr(sort_groupby(esp_exchange(sort_groupby(
> scan(TABLE 'A', path 'TRAFODION.SCH.DWD_ROAM_03_CNGI_SRC', forward
> , blocks_per_access 1 , mdam forced)))));
> The DDL is
> CREATE TABLE TRAFODION.SCH.DWD_ROAM_03_CNGI_SRC
> (
> MSISDN CHAR(11) CHARACTER SET ISO88591 COLLATE
> DEFAULT DEFAULT NULL NOT SERIALIZED
> , START_DATETIME CHAR(14) CHARACTER SET ISO88591 COLLATE
> DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE NOT SERIALIZED
> , APNNI VARCHAR(20) CHARACTER SET ISO88591 COLLATE
> DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE NOT SERIALIZED
> )
> STORE BY (APNNI ASC, START_DATETIME ASC)
> SALT USING 8 PARTITIONS
> ATTRIBUTES ALIGNED FORMAT
> HBASE_OPTIONS
> (
> DATA_BLOCK_ENCODING = 'FAST_DIFF',
> MEMSTORE_FLUSH_SIZE = '1073741824'
> )
> ;
> Stack of core is
> #2 0x00007f57f02bcf50 in assert_botch_abend (f=0x7f57ed2cf99c "../common/Collections.cpp", l=874, m=0x7f57ed2d01f0 "List index exceeds # of entries",
> c=<value optimized out>) at ../export/NAAbort.cpp:285
> #3 0x00007f57ecf22020 in NAList<KeyColumns::KeyColumn*>::operator[] (this=0x7f5779a95cf0, i=6) at ../common/Collections.cpp:874
> 0000004 0x00007f57ecf1a2f6 in ColumnOrderList::validateOrder (this=0x7f5779a95c68, order=6) at ../optimizer/mdam.cpp:3046
> 0000005 0x00007f57ecf1a355 in ColumnOrderList::setStopColumn (this=0x7f5779a95c68, stopColumn=32599) at ../optimizer/mdam.cpp:3091
> 0000006 0x00007f57ecf20c4a in MdamKey::preCodeGen (this=0x7f577acfacb8, executorPredicates=..., selectionPredicates=<value optimized out>, availableValues=...,
> inputValues=..., vegPairsPtr=0x7f57e43684c0, replicateExpression=1, partKeyPredsAdded=1) at ../optimizer/mdam.cpp:1699
> 0000007 0x00007f57ec58eb4c in FileScan::preCodeGen (this=0x7f577ad4b230, generator=0x7f57e43697f0, externalInputs=..., pulledNewInputs=...)
> at ../generator/GenPreCode.cpp:4332
> 0000008 0x00007f57ec58f6bc in HbaseAccess::preCodeGen (this=0x7f577ad4b230, generator=0x7f57e43697f0, externalInputs=<value optimized out>, pulledNewInputs=...)
> at ../generator/GenPreCode.cpp:12919
> 0000009 0x00007f57ec580308 in Exchange::preCodeGen (this=0x7f577ad1c780, generator=0x7f57e43697f0, externalInputs=..., pulledNewInputs=...)
> at ../generator/GenPreCode.cpp:7828
> 0000010 0x00007f57ec583580 in Sort::preCodeGen (this=0x7f5779a83bf0, generator=0x7f57e43697f0, externalInputs=..., pulledNewInputs=...)
> at ../generator/GenPreCode.cpp:7363
> 0000011 0x00007f57ec57b517 in Join::preCodeGen (this=0x7f577ace8560, generator=0x7f57e43697f0, externalInputs=..., pulledNewInputs=...)
> at ../generator/GenPreCode.cpp:2425
> 0000012 0x00007f57ec5967d9 in NestedJoin::preCodeGen (this=0x7f577ace8560, generator=0x7f57e43697f0, externalInputs=..., pulledNewInputs=...)
> at ../generator/GenPreCode.cpp:3151
> 0000013 0x00007f57ec580308 in Exchange::preCodeGen (this=0x7f577acca530, generator=0x7f57e43697f0, externalInputs=..., pulledNewInputs=...)
> at ../generator/GenPreCode.cpp:7828
> 0000014 0x00007f57ec581158 in RelRoot::preCodeGen (this=0x7f577acb1bd8, generator=0x7f57e43697f0, pulledNewInputs=...) at ../generator/GenPreCode.cpp:1986
> 0000015 0x00007f57ec50bb57 in Generator::preGenCode (this=0x7f57e43697f0, expr_node=0x7f577acb1bd8) at ../generator/Generator.cpp:546
> Issue is not seen for serial plans.
> The problem is that during MdamKey::preCodegen we regenerate the disjuncts and expect to get the same number as we saw during optimize phase. This is mostly true, but in some cases not. There is some defensive code to handle this case, but it does not trigger when there is a partKey predicate. The fix removes the partKey predicate check for the defensive code.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)