trafodion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anoop Sharma <anoop.sha...@esgyn.com>
Subject RE: core/TESTRTS failing?
Date Fri, 08 Jan 2016 01:33:39 GMT
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

Mime
View raw message