Derby
  1. Derby
  2. DERBY-1221

runtimestatistics time shows large number instead of 0 with ibm15 on zOS

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 10.1.3.1
    • Fix Version/s: None
    • Component/s: SQL
    • Labels:
      None
    • Environment:
      zOS with ibm15

      Description

      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:
      derbylang/derbylang.fail:lang/aggregateOptimization.sql
      derbylang/derbylang.fail:lang/distinctElimination.sql
      derbylang/derbylang.fail:lang/predicatePushdown.sql
      derbylang/derbylang.fail:lang/predicatesIntoViews.sql
      derbylang/derbylang.fail:lang/staleplans.sql
      derbylang/derbylang.fail:lang/wisconsin.java
      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
            2912a2912
            > Execute Time = -3638779204078642344
            2921 del
            < next time (milliseconds) = 0
            2921a2921
            > next time (milliseconds) = 3638779204078642344
            2934 del
            < next time (milliseconds) = 0
            2934a2934
            > next time (milliseconds) = 3668750241784351640
            2991 del
            < Execute Time = 0
            2991a2991
            > Execute Time = -4015137258338621104
            3000 del
            < next time (milliseconds) = 0
            3000a3000
            > 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.

        Activity

          People

          • Assignee:
            Unassigned
            Reporter:
            Myrna van Lunteren
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development