db-derby-dev mailing list archives

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

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

Knut Anders Hatlen updated DERBY-4678:
--------------------------------------

    Attachment: FetchTest.java

I've tested the patch with the attached Java class (FetchTest.java). To create the database,
execute "java FetchTest init", and to run the test, execute "java FetchTest".

The test operates on a table with 2000 rows, each row consists of two integers. There's an
index on one of the columns, and the test uses this index to access all the rows with the
statement

  SELECT * FROM T --DERBY-PROPERTIES index=idx

Since the index is not covering all the columns, the heap must be read using the RowLocation
found in the index, and this is where the 3-arg fetch() method is called, once per row in
the table.

I have run this test 40 times with a clean trunk and 40 times with the patch (insane jars,
test runs interleaved and in random order, 20 seconds warmup and 40 seconds data collection
per test run). No significant difference was found. The average throughput of these runs was
0.2% higher with the patch than with clean trunk (294.05 ops/s vs 294.70 ops/s, standard deviation
13.0).

fetch() is only used to map index rows to heap rows, and it won't be used in a pure index
scan or in a pure table scan, so this was the most relevant test I could think of. If someone
has ideas for better ways to test it, please let me know.

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


Mime
View raw message