You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafodion.apache.org by Eric Owhadi <er...@esgyn.com> on 2016/03/18 16:40:32 UTC
SEABASE/TEST010 error?
Hi Trafodioneers,
Trying to pass regression tests for my next pull request, but stumbled on
failure on SEABASE/TEST010
Given that my changes have nothing to do around compiler, there is no way
it could have affected this.
Any clue?
To me, the index_scan is the correct plan, so look like the EXPECTED010 is
wrong?
DIFF010 is :
10502c10502
< . . 1 TRAFODION_SCAN T010T4 1.00E+009
---
> . . 1 TRAFODION_index_scan T010IX1 1.00E+009
Where this is the LOG associated:
>>showddl t010t4 ;
CREATE TABLE TRAFODION.SCH.T010T4
(
A INT NO DEFAULT NOT NULL NOT DROPPABLE
, B INT DEFAULT NULL
, C INT DEFAULT NULL
, PRIMARY KEY (A ASC)
)
SALT USING 4 PARTITIONS
;
CREATE INDEX T010IX1 ON TRAFODION.SCH.T010T4
(
B ASC
)
HBASE_OPTIONS
(
DATA_BLOCK_ENCODING = 'FAST_DIFF',
COMPRESSION = 'GZ'
)
SALT LIKE TABLE
;
--- SQL operation complete.
>>insert into t010t4 values (1,1,1) ;
--- 1 row(s) inserted.
>>prepare s from select a from t010t4 <<+cardinality 10e8>> where b > 0 ;
--- SQL command prepared.
>>explain options 'f' s ;
LC RC OP OPERATOR OPT DESCRIPTION CARD
---- ---- ---- -------------------- -------- --------------------
---------
1 . 2 root
1.00E+009
. . 1 trafodion_index_scan T010IX1
1.00E+009
--- SQL operation complete.
RE: SEABASE/TEST010 error?
Posted by Eric Owhadi <er...@esgyn.com>.
Actually, I found the root cause.
I had modified a function that looked weird in a test branch:
NABoolean FileScanOptimizer::isMultipleProbes() const
{
CostScalar repeatCount = getContext().getPlan()->getPhysicalProperty()->
getDP2CostThatDependsOnSPP()->getRepeatCountForOperatorsInDP2() ;
CollIndex numCols =
getContext().getInputLogProp()->getColStats().entries();
return (repeatCount.isGreaterThanOne()) OR (numCols > 0);
}
And instead forced it to return true always, just for test. As I noticed
that this would always return false, while I would expect it to return true
if I understand what the name of the function means.
And I had forgotten that file change when working on this new PR. I guess
git checkout –b “newbranch” is not behaving the way I would expect since
it did not restore the file from my test branch…
When restoring the original file, the test passed.
BUT I still don’t believe not using INDEX scan is correct. Index mdam scan
should be better.
So I suspect that what I discovered on this isMultipleProbes is really a
bug, even if I am far from understanding the whole MDAM compiler business.
Thought?
Eric
*From:* Eric Owhadi [mailto:eric.owhadi@esgyn.com]
*Sent:* Friday, March 18, 2016 10:41 AM
*To:* 'dev@trafodion.incubator.apache.org' <
dev@trafodion.incubator.apache.org>
*Subject:* SEABASE/TEST010 error?
Hi Trafodioneers,
Trying to pass regression tests for my next pull request, but stumbled on
failure on SEABASE/TEST010
Given that my changes have nothing to do around compiler, there is no way
it could have affected this.
Any clue?
To me, the index_scan is the correct plan, so look like the EXPECTED010 is
wrong?
DIFF010 is :
10502c10502
< . . 1 TRAFODION_SCAN T010T4 1.00E+009
---
> . . 1 TRAFODION_index_scan T010IX1 1.00E+009
Where this is the LOG associated:
>>showddl t010t4 ;
CREATE TABLE TRAFODION.SCH.T010T4
(
A INT NO DEFAULT NOT NULL NOT DROPPABLE
, B INT DEFAULT NULL
, C INT DEFAULT NULL
, PRIMARY KEY (A ASC)
)
SALT USING 4 PARTITIONS
;
CREATE INDEX T010IX1 ON TRAFODION.SCH.T010T4
(
B ASC
)
HBASE_OPTIONS
(
DATA_BLOCK_ENCODING = 'FAST_DIFF',
COMPRESSION = 'GZ'
)
SALT LIKE TABLE
;
--- SQL operation complete.
>>insert into t010t4 values (1,1,1) ;
--- 1 row(s) inserted.
>>prepare s from select a from t010t4 <<+cardinality 10e8>> where b > 0 ;
--- SQL command prepared.
>>explain options 'f' s ;
LC RC OP OPERATOR OPT DESCRIPTION CARD
---- ---- ---- -------------------- -------- --------------------
---------
1 . 2 root
1.00E+009
. . 1 trafodion_index_scan T010IX1
1.00E+009
--- SQL operation complete.