[
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.
