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/01/07 15:22:42 UTC
core/TESTRTS failing?
Sorry to bother,
But after syncing the new predicate push down code with latest master,
re-running regression test, I am getting a fail on core/TESTRTS with this
diff:
Is it a known problem or should I investigate it?
Eric
1895c1895
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
1944c1944
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2391c2391
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2440c2440
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2490c2490
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2730c2730
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2782c2782
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
RE: core/TESTRTS failing?
Posted by Selva Govindarajan <se...@esgyn.com>.
No problem. Just wanted to clarify that bytesRead calculation is based on
the size of colValue, colName and the rowID read in the JNI layer of the
Trafodion. It is NOT based on the size of the data exchanged between the
client and RS.
Selva
-----Original Message-----
From: Eric Owhadi [mailto:eric.owhadi@esgyn.com]
Sent: Thursday, January 7, 2016 5:48 PM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
Ok 2 votes for EXPECTEDTESTRTS, EXPECTEDTESTRTS it is.
No big deal anyway,
Eric
-----Original Message-----
From: Anoop Sharma [mailto:anoop.sharma@esgyn.com]
Sent: Thursday, January 7, 2016 7:34 PM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
bytesread should be fairly constant since the number of returned rows is
deterministic.
Also since this test has not failed for a while which indicates that the
older number of bytes has been consistent.
My input would be to change the expected file with the new number instead of
changing the filter.
If it turns out that the returned bytes are inconsistent in the next few
days, then the filter could be updated (Though it would be good to determine
why that inconsistency is showing).
anoop
-----Original Message-----
From: Eric Owhadi [mailto:eric.owhadi@esgyn.com]
Sent: Thursday, January 7, 2016 5:28 PM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
OK, it is counter intuitive to me as I would think this particular value is
deterministic, but if this is the way TESTRTS is supposed to be then I'll do
per your suggestion. Anyone else have opinion on this?
FYI, the optimization check in question is tested also in a new TEST140
under executor that will come with predicate pushdown V2.
Cheers,
Eric
-----Original Message-----
From: Selva Govindarajan [mailto:selva.govindarajan@esgyn.com]
Sent: Thursday, January 7, 2016 7:09 PM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
I would think it would be better if you can filter it out. It is done that
way for all other operators. All the metrics are ignored because it can vary
from run to run. My suggestion is not to use core/TESTRTS to detect/vouch
optimizations done to the code.
Selva
-----Original Message-----
From: Eric Owhadi [mailto:eric.owhadi@esgyn.com]
Sent: Thursday, January 7, 2016 5:00 PM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
OK, so I verified the root cause of this delta. Indeed the difference in
read byte comes from the new optimization. 2 columns are optimized out,
resulting in 53% decrease in byte read.
So I will not filter this out, I will create a new EXPECTED TESTRTS,
anything going back to non optimized value should fail test.
Thanks for your help identifying the meaning of this number, Eric
-----Original Message-----
From: Selva Govindarajan [mailto:selva.govindarajan@esgyn.com]
Sent: Thursday, January 7, 2016 9:57 AM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
The 120 and 252 are the bytesRead for this table. It looks like there is a
difference in bytesRead; lesser the better. I would think it should be ok
to have a difference in bytes read based on the optimization.
Selva
-----Original Message-----
From: Eric Owhadi [mailto:eric.owhadi@esgyn.com]
Sent: Thursday, January 7, 2016 7:01 AM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
So from a semantic standpoint it is normal to have these diffs? They should
be filtered out?
If so, I can make the change to make it pass?
Eric
-----Original Message-----
From: Selva Govindarajan [mailto:selva.govindarajan@esgyn.com]
Sent: Thursday, January 7, 2016 8:48 AM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
This could be due to a filter issue for TESTRTS. Please consider making this
change in FILTERRTS From s/EX_TRAF_KEY_SELECT[ ]*[0-9,
|]*/EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@/ to
s/EX_TRAF_KEY_SELECT[ ]*[A-Z0-9, |#]*/EX_TRAF_KEY_SELECT
@exTrafKeySelectCounters@/
You can just run the command to produce the difference without running the
test again with -diff option of runregr command.
Selva
-----Original Message-----
From: Eric Owhadi [mailto:eric.owhadi@esgyn.com]
Sent: Thursday, January 7, 2016 6:23 AM
To: dev@trafodion.incubator.apache.org
Subject: core/TESTRTS failing?
Sorry to bother,
But after syncing the new predicate push down code with latest master,
re-running regression test, I am getting a fail on core/TESTRTS with this
diff:
Is it a known problem or should I investigate it?
Eric
1895c1895
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
1944c1944
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2391c2391
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2440c2440
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2490c2490
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2730c2730
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2782c2782
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
RE: core/TESTRTS failing?
Posted by Eric Owhadi <er...@esgyn.com>.
Ok 2 votes for EXPECTEDTESTRTS, EXPECTEDTESTRTS it is.
No big deal anyway,
Eric
-----Original Message-----
From: Anoop Sharma [mailto:anoop.sharma@esgyn.com]
Sent: Thursday, January 7, 2016 7:34 PM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
bytesread should be fairly constant since the number of returned rows is
deterministic.
Also since this test has not failed for a while which indicates that the
older number of bytes has been consistent.
My input would be to change the expected file with the new number instead of
changing the filter.
If it turns out that the returned bytes are inconsistent in the next few
days, then the filter could be updated (Though it would be good to determine
why that inconsistency is showing).
anoop
-----Original Message-----
From: Eric Owhadi [mailto:eric.owhadi@esgyn.com]
Sent: Thursday, January 7, 2016 5:28 PM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
OK, it is counter intuitive to me as I would think this particular value is
deterministic, but if this is the way TESTRTS is supposed to be then I'll do
per your suggestion. Anyone else have opinion on this?
FYI, the optimization check in question is tested also in a new TEST140
under executor that will come with predicate pushdown V2.
Cheers,
Eric
-----Original Message-----
From: Selva Govindarajan [mailto:selva.govindarajan@esgyn.com]
Sent: Thursday, January 7, 2016 7:09 PM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
I would think it would be better if you can filter it out. It is done that
way for all other operators. All the metrics are ignored because it can vary
from run to run. My suggestion is not to use core/TESTRTS to detect/vouch
optimizations done to the code.
Selva
-----Original Message-----
From: Eric Owhadi [mailto:eric.owhadi@esgyn.com]
Sent: Thursday, January 7, 2016 5:00 PM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
OK, so I verified the root cause of this delta. Indeed the difference in
read byte comes from the new optimization. 2 columns are optimized out,
resulting in 53% decrease in byte read.
So I will not filter this out, I will create a new EXPECTED TESTRTS,
anything going back to non optimized value should fail test.
Thanks for your help identifying the meaning of this number, Eric
-----Original Message-----
From: Selva Govindarajan [mailto:selva.govindarajan@esgyn.com]
Sent: Thursday, January 7, 2016 9:57 AM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
The 120 and 252 are the bytesRead for this table. It looks like there is a
difference in bytesRead; lesser the better. I would think it should be ok
to have a difference in bytes read based on the optimization.
Selva
-----Original Message-----
From: Eric Owhadi [mailto:eric.owhadi@esgyn.com]
Sent: Thursday, January 7, 2016 7:01 AM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
So from a semantic standpoint it is normal to have these diffs? They should
be filtered out?
If so, I can make the change to make it pass?
Eric
-----Original Message-----
From: Selva Govindarajan [mailto:selva.govindarajan@esgyn.com]
Sent: Thursday, January 7, 2016 8:48 AM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
This could be due to a filter issue for TESTRTS. Please consider making this
change in FILTERRTS From s/EX_TRAF_KEY_SELECT[ ]*[0-9,
|]*/EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@/ to
s/EX_TRAF_KEY_SELECT[ ]*[A-Z0-9, |#]*/EX_TRAF_KEY_SELECT
@exTrafKeySelectCounters@/
You can just run the command to produce the difference without running the
test again with -diff option of runregr command.
Selva
-----Original Message-----
From: Eric Owhadi [mailto:eric.owhadi@esgyn.com]
Sent: Thursday, January 7, 2016 6:23 AM
To: dev@trafodion.incubator.apache.org
Subject: core/TESTRTS failing?
Sorry to bother,
But after syncing the new predicate push down code with latest master,
re-running regression test, I am getting a fail on core/TESTRTS with this
diff:
Is it a known problem or should I investigate it?
Eric
1895c1895
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
1944c1944
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2391c2391
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2440c2440
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2490c2490
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2730c2730
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2782c2782
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
RE: core/TESTRTS failing?
Posted by Anoop Sharma <an...@esgyn.com>.
bytesread should be fairly constant since the number of returned rows is
deterministic.
Also since this test has not failed for a while which indicates that the
older number of
bytes has been consistent.
My input would be to change the expected file with the new number instead of
changing the filter.
If it turns out that the returned bytes are inconsistent in the next few
days, then
the filter could be updated (Though it would be good to determine why that
inconsistency is showing).
anoop
-----Original Message-----
From: Eric Owhadi [mailto:eric.owhadi@esgyn.com]
Sent: Thursday, January 7, 2016 5:28 PM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
OK, it is counter intuitive to me as I would think this particular value is
deterministic, but if this is the way TESTRTS is supposed to be then I'll do
per your suggestion. Anyone else have opinion on this?
FYI, the optimization check in question is tested also in a new TEST140
under executor that will come with predicate pushdown V2.
Cheers,
Eric
-----Original Message-----
From: Selva Govindarajan [mailto:selva.govindarajan@esgyn.com]
Sent: Thursday, January 7, 2016 7:09 PM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
I would think it would be better if you can filter it out. It is done that
way for all other operators. All the metrics are ignored because it can vary
from run to run. My suggestion is not to use core/TESTRTS to detect/vouch
optimizations done to the code.
Selva
-----Original Message-----
From: Eric Owhadi [mailto:eric.owhadi@esgyn.com]
Sent: Thursday, January 7, 2016 5:00 PM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
OK, so I verified the root cause of this delta. Indeed the difference in
read byte comes from the new optimization. 2 columns are optimized out,
resulting in 53% decrease in byte read.
So I will not filter this out, I will create a new EXPECTED TESTRTS,
anything going back to non optimized value should fail test.
Thanks for your help identifying the meaning of this number, Eric
-----Original Message-----
From: Selva Govindarajan [mailto:selva.govindarajan@esgyn.com]
Sent: Thursday, January 7, 2016 9:57 AM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
The 120 and 252 are the bytesRead for this table. It looks like there is a
difference in bytesRead; lesser the better. I would think it should be ok
to have a difference in bytes read based on the optimization.
Selva
-----Original Message-----
From: Eric Owhadi [mailto:eric.owhadi@esgyn.com]
Sent: Thursday, January 7, 2016 7:01 AM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
So from a semantic standpoint it is normal to have these diffs? They should
be filtered out?
If so, I can make the change to make it pass?
Eric
-----Original Message-----
From: Selva Govindarajan [mailto:selva.govindarajan@esgyn.com]
Sent: Thursday, January 7, 2016 8:48 AM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
This could be due to a filter issue for TESTRTS. Please consider making this
change in FILTERRTS From s/EX_TRAF_KEY_SELECT[ ]*[0-9,
|]*/EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@/ to
s/EX_TRAF_KEY_SELECT[ ]*[A-Z0-9, |#]*/EX_TRAF_KEY_SELECT
@exTrafKeySelectCounters@/
You can just run the command to produce the difference without running the
test again with -diff option of runregr command.
Selva
-----Original Message-----
From: Eric Owhadi [mailto:eric.owhadi@esgyn.com]
Sent: Thursday, January 7, 2016 6:23 AM
To: dev@trafodion.incubator.apache.org
Subject: core/TESTRTS failing?
Sorry to bother,
But after syncing the new predicate push down code with latest master,
re-running regression test, I am getting a fail on core/TESTRTS with this
diff:
Is it a known problem or should I investigate it?
Eric
1895c1895
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
1944c1944
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2391c2391
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2440c2440
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2490c2490
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2730c2730
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2782c2782
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
RE: core/TESTRTS failing?
Posted by Eric Owhadi <er...@esgyn.com>.
OK, it is counter intuitive to me as I would think this particular value is
deterministic, but if this is the way TESTRTS is supposed to be then I'll do
per your suggestion. Anyone else have opinion on this?
FYI, the optimization check in question is tested also in a new TEST140
under executor that will come with predicate pushdown V2.
Cheers,
Eric
-----Original Message-----
From: Selva Govindarajan [mailto:selva.govindarajan@esgyn.com]
Sent: Thursday, January 7, 2016 7:09 PM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
I would think it would be better if you can filter it out. It is done that
way for all other operators. All the metrics are ignored because it can vary
from run to run. My suggestion is not to use core/TESTRTS to detect/vouch
optimizations done to the code.
Selva
-----Original Message-----
From: Eric Owhadi [mailto:eric.owhadi@esgyn.com]
Sent: Thursday, January 7, 2016 5:00 PM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
OK, so I verified the root cause of this delta. Indeed the difference in
read byte comes from the new optimization. 2 columns are optimized out,
resulting in 53% decrease in byte read.
So I will not filter this out, I will create a new EXPECTED TESTRTS,
anything going back to non optimized value should fail test.
Thanks for your help identifying the meaning of this number, Eric
-----Original Message-----
From: Selva Govindarajan [mailto:selva.govindarajan@esgyn.com]
Sent: Thursday, January 7, 2016 9:57 AM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
The 120 and 252 are the bytesRead for this table. It looks like there is a
difference in bytesRead; lesser the better. I would think it should be ok
to have a difference in bytes read based on the optimization.
Selva
-----Original Message-----
From: Eric Owhadi [mailto:eric.owhadi@esgyn.com]
Sent: Thursday, January 7, 2016 7:01 AM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
So from a semantic standpoint it is normal to have these diffs? They should
be filtered out?
If so, I can make the change to make it pass?
Eric
-----Original Message-----
From: Selva Govindarajan [mailto:selva.govindarajan@esgyn.com]
Sent: Thursday, January 7, 2016 8:48 AM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
This could be due to a filter issue for TESTRTS. Please consider making this
change in FILTERRTS From s/EX_TRAF_KEY_SELECT[ ]*[0-9,
|]*/EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@/ to
s/EX_TRAF_KEY_SELECT[ ]*[A-Z0-9, |#]*/EX_TRAF_KEY_SELECT
@exTrafKeySelectCounters@/
You can just run the command to produce the difference without running the
test again with -diff option of runregr command.
Selva
-----Original Message-----
From: Eric Owhadi [mailto:eric.owhadi@esgyn.com]
Sent: Thursday, January 7, 2016 6:23 AM
To: dev@trafodion.incubator.apache.org
Subject: core/TESTRTS failing?
Sorry to bother,
But after syncing the new predicate push down code with latest master,
re-running regression test, I am getting a fail on core/TESTRTS with this
diff:
Is it a known problem or should I investigate it?
Eric
1895c1895
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
1944c1944
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2391c2391
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2440c2440
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2490c2490
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2730c2730
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2782c2782
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
RE: core/TESTRTS failing?
Posted by Selva Govindarajan <se...@esgyn.com>.
I would think it would be better if you can filter it out. It is done that
way for all other operators. All the metrics are ignored because it can vary
from run to run. My suggestion is not to use core/TESTRTS to detect/vouch
optimizations done to the code.
Selva
-----Original Message-----
From: Eric Owhadi [mailto:eric.owhadi@esgyn.com]
Sent: Thursday, January 7, 2016 5:00 PM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
OK, so I verified the root cause of this delta. Indeed the difference in
read byte comes from the new optimization. 2 columns are optimized out,
resulting in 53% decrease in byte read.
So I will not filter this out, I will create a new EXPECTED TESTRTS,
anything going back to non optimized value should fail test.
Thanks for your help identifying the meaning of this number, Eric
-----Original Message-----
From: Selva Govindarajan [mailto:selva.govindarajan@esgyn.com]
Sent: Thursday, January 7, 2016 9:57 AM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
The 120 and 252 are the bytesRead for this table. It looks like there is a
difference in bytesRead; lesser the better. I would think it should be ok
to have a difference in bytes read based on the optimization.
Selva
-----Original Message-----
From: Eric Owhadi [mailto:eric.owhadi@esgyn.com]
Sent: Thursday, January 7, 2016 7:01 AM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
So from a semantic standpoint it is normal to have these diffs? They should
be filtered out?
If so, I can make the change to make it pass?
Eric
-----Original Message-----
From: Selva Govindarajan [mailto:selva.govindarajan@esgyn.com]
Sent: Thursday, January 7, 2016 8:48 AM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
This could be due to a filter issue for TESTRTS. Please consider making this
change in FILTERRTS From s/EX_TRAF_KEY_SELECT[ ]*[0-9,
|]*/EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@/ to
s/EX_TRAF_KEY_SELECT[ ]*[A-Z0-9, |#]*/EX_TRAF_KEY_SELECT
@exTrafKeySelectCounters@/
You can just run the command to produce the difference without running the
test again with -diff option of runregr command.
Selva
-----Original Message-----
From: Eric Owhadi [mailto:eric.owhadi@esgyn.com]
Sent: Thursday, January 7, 2016 6:23 AM
To: dev@trafodion.incubator.apache.org
Subject: core/TESTRTS failing?
Sorry to bother,
But after syncing the new predicate push down code with latest master,
re-running regression test, I am getting a fail on core/TESTRTS with this
diff:
Is it a known problem or should I investigate it?
Eric
1895c1895
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
1944c1944
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2391c2391
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2440c2440
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2490c2490
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2730c2730
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2782c2782
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
RE: core/TESTRTS failing?
Posted by Eric Owhadi <er...@esgyn.com>.
OK, so I verified the root cause of this delta. Indeed the difference in
read byte comes from the new optimization. 2 columns are optimized out,
resulting in 53% decrease in byte read.
So I will not filter this out, I will create a new EXPECTED TESTRTS,
anything going back to non optimized value should fail test.
Thanks for your help identifying the meaning of this number,
Eric
-----Original Message-----
From: Selva Govindarajan [mailto:selva.govindarajan@esgyn.com]
Sent: Thursday, January 7, 2016 9:57 AM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
The 120 and 252 are the bytesRead for this table. It looks like there is a
difference in bytesRead; lesser the better. I would think it should be ok
to have a difference in bytes read based on the optimization.
Selva
-----Original Message-----
From: Eric Owhadi [mailto:eric.owhadi@esgyn.com]
Sent: Thursday, January 7, 2016 7:01 AM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
So from a semantic standpoint it is normal to have these diffs? They should
be filtered out?
If so, I can make the change to make it pass?
Eric
-----Original Message-----
From: Selva Govindarajan [mailto:selva.govindarajan@esgyn.com]
Sent: Thursday, January 7, 2016 8:48 AM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
This could be due to a filter issue for TESTRTS. Please consider making this
change in FILTERRTS From s/EX_TRAF_KEY_SELECT[ ]*[0-9,
|]*/EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@/ to
s/EX_TRAF_KEY_SELECT[ ]*[A-Z0-9, |#]*/EX_TRAF_KEY_SELECT
@exTrafKeySelectCounters@/
You can just run the command to produce the difference without running the
test again with -diff option of runregr command.
Selva
-----Original Message-----
From: Eric Owhadi [mailto:eric.owhadi@esgyn.com]
Sent: Thursday, January 7, 2016 6:23 AM
To: dev@trafodion.incubator.apache.org
Subject: core/TESTRTS failing?
Sorry to bother,
But after syncing the new predicate push down code with latest master,
re-running regression test, I am getting a fail on core/TESTRTS with this
diff:
Is it a known problem or should I investigate it?
Eric
1895c1895
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
1944c1944
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2391c2391
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2440c2440
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2490c2490
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2730c2730
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2782c2782
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
RE: core/TESTRTS failing?
Posted by Selva Govindarajan <se...@esgyn.com>.
The 120 and 252 are the bytesRead for this table. It looks like there is a
difference in bytesRead; lesser the better. I would think it should be ok
to have a difference in bytes read based on the optimization.
Selva
-----Original Message-----
From: Eric Owhadi [mailto:eric.owhadi@esgyn.com]
Sent: Thursday, January 7, 2016 7:01 AM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
So from a semantic standpoint it is normal to have these diffs? They should
be filtered out?
If so, I can make the change to make it pass?
Eric
-----Original Message-----
From: Selva Govindarajan [mailto:selva.govindarajan@esgyn.com]
Sent: Thursday, January 7, 2016 8:48 AM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
This could be due to a filter issue for TESTRTS. Please consider making this
change in FILTERRTS From s/EX_TRAF_KEY_SELECT[ ]*[0-9,
|]*/EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@/ to
s/EX_TRAF_KEY_SELECT[ ]*[A-Z0-9, |#]*/EX_TRAF_KEY_SELECT
@exTrafKeySelectCounters@/
You can just run the command to produce the difference without running the
test again with -diff option of runregr command.
Selva
-----Original Message-----
From: Eric Owhadi [mailto:eric.owhadi@esgyn.com]
Sent: Thursday, January 7, 2016 6:23 AM
To: dev@trafodion.incubator.apache.org
Subject: core/TESTRTS failing?
Sorry to bother,
But after syncing the new predicate push down code with latest master,
re-running regression test, I am getting a fail on core/TESTRTS with this
diff:
Is it a known problem or should I investigate it?
Eric
1895c1895
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
1944c1944
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2391c2391
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2440c2440
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2490c2490
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2730c2730
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2782c2782
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
RE: core/TESTRTS failing?
Posted by Eric Owhadi <er...@esgyn.com>.
So from a semantic standpoint it is normal to have these diffs? They should
be filtered out?
If so, I can make the change to make it pass?
Eric
-----Original Message-----
From: Selva Govindarajan [mailto:selva.govindarajan@esgyn.com]
Sent: Thursday, January 7, 2016 8:48 AM
To: dev@trafodion.incubator.apache.org
Subject: RE: core/TESTRTS failing?
This could be due to a filter issue for TESTRTS. Please consider making this
change in FILTERRTS From s/EX_TRAF_KEY_SELECT[ ]*[0-9,
|]*/EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@/ to
s/EX_TRAF_KEY_SELECT[ ]*[A-Z0-9, |#]*/EX_TRAF_KEY_SELECT
@exTrafKeySelectCounters@/
You can just run the command to produce the difference without running the
test again with -diff option of runregr command.
Selva
-----Original Message-----
From: Eric Owhadi [mailto:eric.owhadi@esgyn.com]
Sent: Thursday, January 7, 2016 6:23 AM
To: dev@trafodion.incubator.apache.org
Subject: core/TESTRTS failing?
Sorry to bother,
But after syncing the new predicate push down code with latest master,
re-running regression test, I am getting a fail on core/TESTRTS with this
diff:
Is it a known problem or should I investigate it?
Eric
1895c1895
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
1944c1944
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2391c2391
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2440c2440
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2490c2490
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2730c2730
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2782c2782
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
RE: core/TESTRTS failing?
Posted by Selva Govindarajan <se...@esgyn.com>.
This could be due to a filter issue for TESTRTS. Please consider making this
change in FILTERRTS
From
s/EX_TRAF_KEY_SELECT[ ]*[0-9, |]*/EX_TRAF_KEY_SELECT
@exTrafKeySelectCounters@/
to
s/EX_TRAF_KEY_SELECT[ ]*[A-Z0-9, |#]*/EX_TRAF_KEY_SELECT
@exTrafKeySelectCounters@/
You can just run the command to produce the difference without running the
test again with -diff option of runregr command.
Selva
-----Original Message-----
From: Eric Owhadi [mailto:eric.owhadi@esgyn.com]
Sent: Thursday, January 7, 2016 6:23 AM
To: dev@trafodion.incubator.apache.org
Subject: core/TESTRTS failing?
Sorry to bother,
But after syncing the new predicate push down code with latest master,
re-running regression test, I am getting a fail on core/TESTRTS with this
diff:
Is it a known problem or should I investigate it?
Eric
1895c1895
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
1944c1944
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2391c2391
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2440c2440
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2490c2490
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2730c2730
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120
2782c2782
< . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|252
---
> . . 1 2 1 3 EX_TRAF_KEY_SELECT @exTrafKeySelectCounters@
#CAT.#SCH.TSTAT|4|120