db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren (JIRA)" <derby-...@db.apache.org>
Subject [jira] Created: (DERBY-1221) runtimestatistics time shows large number instead of 0 with ibm15 on zOS
Date Fri, 14 Apr 2006 07:26:00 GMT
runtimestatistics time shows large number instead of 0 with ibm15 on zOS

         Key: DERBY-1221
         URL: http://issues.apache.org/jira/browse/DERBY-1221
     Project: Derby
        Type: Bug

 Environment: zOS with ibm15
    Reporter: Myrna van Lunteren

A number of tests that printout runtimestatistics fail on zOS with ibm15, because instead
of a 'time' of 0, the time is some large number.

Tests that fail like this:
encryptionAll/encryption/storemats.fail:store/access.sql (in various encryption schemes)

This is the kind of diff I see:
*** Start: access jdk1.5.0 storemats:storemats 2006-04-13 09:46:01 ***
2912 del
< Execute Time = 0
> Execute Time = -3638779204078642344
2921 del
<               next time (milliseconds) = 0
>               next time (milliseconds) = 3638779204078642344
2934 del
<                       next time (milliseconds) = 0
>                       next time (milliseconds) = 3668750241784351640
2991 del
< Execute Time = 0
> Execute Time = -4015137258338621104
3000 del
<               next time (milliseconds) = 0
>               next time (milliseconds) = 4015137258338621104

As this problem occurs only with ibm15 and not with ibm14, I think somewhere in the runtime
statistics printing code we may be using BigDecimal somehow, and it's not done in an encoding-safe
way. But that is just a guess.

I'm leaving this one as Major, because it's easy to miss things when looking through test
failures this way, but I can also understand that this would be considered minor, as apparently
the paths taken by the optimizer are actually correct and it's only the printing out that
has the large numbers. Yet again on the other hand I imagine it makes runtimestatistics less
useful, with these disconcertingly large number of milliseconds. 

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message