db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4678) Avoid code duplication in GenericConglomerateController.fetch()
Date Fri, 28 May 2010 16:19:38 GMT

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

View raw message