[jira] Closed: (DERBY-4678) Avoid code duplication in GenericConglomerateController.fetch()

["Knut Anders Hatlen (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DERBY-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Knut Anders Hatlen closed DERBY-4678.
-------------------------------------

    Issue & fix info:   (was: [Patch Available])
          Resolution: Won't Fix

I changed the test to use a table with 1 million rows, and increased the size of the page cache so that it could hold the entire table + index and reran the test. I also increased the time each test ran from 20s+40s to 40s+60s (that is, 40s warmup, 60s data collection). With 250 runs with each jar, I now see that the patched version gives 0.8% lower throughput on average than trunk. I also added a variant where the calls to fetch/3 in IndexToBaseRowResultSet are replaced with calls to fetch/4, and a 0.8% decrease was observed there as well.

Since these results show the averages of a fairly high number of runs, and they are also consistent with some shorter test (20s+40s, 100 runs per jar) that I ran before this last experiment, I think there's a high probability that the decrease we see is real, and not just random variation. Having an extra method won't cause any big problems for DERBY-4676, so I guess it's not worthwhile to make this change. I'm therefore closing the issue as Won't Fix.

(I see I didn't mention this in my previous comment, so, for the record, all the tests were performed on a dual-cpu AMD Opteron running OpenSolaris 2009.06 and Sun's Java SE 6u20.)

> Avoid code duplication in GenericConglomerateController.fetch()
> ---------------------------------------------------------------
>
>                 Key: DERBY-4678
>                 URL: https://issues.apache.org/jira/browse/DERBY-4678
>             Project: Derby
>          Issue Type: Improvement
>          Components: Store
>    Affects Versions: 10.7.0.0
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: derby-4678-1a.diff, fetch.diff, FetchTest.java
>
>
> GenericConglomerateController has two methods named fetch(). One of these methods has a parameter called waitForLock, whereas the other one doesn't have such a parameter. When I diffed the two methods, the only difference I found, apart from a couple of whitespace diffs, was that the method with the waitForLock parameter called lockPosititionForRead/lockPositionForWrite using the parameter value, and the other method called them with a hard-coded value of true.
> To avoid duplication of code, fetch(RowLocation,DataValueDescriptor[],FormatableBitSet) should forward calls to fetch(RowLocation,DataValueDescriptor[],FormatableBitSet,boolean).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.