[
https://issues.apache.org/jira/browse/DERBY-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508552
]
Knut Anders Hatlen commented on DERBY-2857:
-------------------------------------------
Fixing DERBY-2878 would be a better way to solve the problem addressed by
unlockScan.diff.
> Store API should allow PageKey to identify the requested page
> -------------------------------------------------------------
>
> Key: DERBY-2857
> URL: https://issues.apache.org/jira/browse/DERBY-2857
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.4.0.0
> Reporter: Knut Anders Hatlen
> Priority: Minor
> Attachments: getPage.diff, unlockScan.diff
>
>
> Derby allocates more PageKey objects than it has to. For instance, when
> selecting one record using an index, it allocates two PageKey instances
> identifying the leaf node in the B-tree, and three PageKey instances
> identifying the data page. Some of these allocations could easily be avoided
> if the store API had methods which took a PageKey object instead of the page
> number as a long integer.
> As an example, a typical caller of ContainerHandle.getPage(long) already has
> a reference to the PageKey for the page it wants to access. It then calls
> getPageNumber() on the PageKey and passes the page number to getPage()
> p = getContainer().getPage(getPageId().getPageNumber());
> The call to getPage() ends up calling FileContainer.getUserPage() which
> recreates a PageKey object identical to the one the caller had:
> PageKey pageSearch = new PageKey(identity, pageNumber);
> BasePage page = (BasePage)pageCache.find(pageSearch);
> If the caller is allowed to pass down a reference to the PageKey object it
> has, this allocation can be avoided.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
