[
https://issues.apache.org/jira/browse/DERBY-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Matrigali updated DERBY-4678:
----------------------------------
The test case seems like the most likely hot path. I think this path simulates
the type of usage one will see in million row joins using indexes, which is the
kind of usage I am thinking about. I would probably have picked way more rows
like
1 million or 10 million - just to stress the store system more rather than the
querry execution system.
I am not sure why the new patch would go any faster than the old code. With
the standard deviation, is it likely we can't trust any difference +/- 13. So
the test won't tell anything +/- 4%. The most difference I would expect for
this kind of
optimization would be under 0.5% and probably more likley 0.1%.
Given that a different bug fix is driving the change other than just cleaning
code, I would be fine with the change as is into the trunk. If you don't plan
on
getting rid of the 3 arg fetch() as part of the immediate work, could you just
go
ahead and log another JIRA to track that work.
> 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.
