[
https://issues.apache.org/jira/browse/TRAFODION-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210467#comment-16210467
]
ASF GitHub Bot commented on TRAFODION-2776:
-------------------------------------------
Github user asfgit closed the pull request at:
https://github.com/apache/incubator-trafodion/pull/1268
> 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)
