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