Uploaded image for project: 'Derby'
  1. Derby
  2. DERBY-1876

Investigate overhead of JDBC layer and compiled activation code for simple embedded read-only, forward ResultSets

Attach filesAttach ScreenshotVotersWatch issueWatchersCreate sub-taskLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Closed
    • Minor
    • Resolution: Fixed
    • 10.6.1.0
    • 10.6.1.0
    • JDBC
    • None
    • Performance

    Description

      For simple ResultSet usage like:
      ResultSet rs = ps.executeQuery();
      while (rs.next())

      { rs.getInt(1); rs.getInt(2); rs.getInt(3); }

      rs.close();

      it would be interesting to see how much overhead could be removed with simple changes, or possibly removed if there was a simple ResultSet implementation for forward only, read-only ResultSet, and the more complete implementation for all other ResultSet types such as updateable and/or scrollable. Has introducing updateable ResultSets, for example, degraded the performance of read-only ResultSets? Could code be changed so that a typical read-only Resultset is not affected by the code required for richer ResultSets?

      Attachments

        1. derby1862.java
          2 kB
          Daniel John Debrunner
        2. derby1876.java
          1 kB
          Daniel John Debrunner
        3. ers_current_row.txt
          5 kB
          Daniel John Debrunner
        4. timeout_colcount.diff
          3 kB
          Knut Anders Hatlen

        Issue Links

        Activity

          This comment will be Viewable by All Users Viewable by All Users
          Cancel

          People

            Unassigned Unassigned
            djd Daniel John Debrunner
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Slack

                Issue deployment