[jira] Updated: (DERBY-2857) Store API should allow PageKey to identify the requested page

["Knut Anders Hatlen (JIRA)" <ji...@apache.org>]

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

Knut Anders Hatlen updated DERBY-2857:
--------------------------------------

    Attachment: getPage.diff
                unlockScan.diff

Attaching two patches which show how some of the allocations could be avoided. They are provided as examples only, and are not intended for commit.

unlockScan.diff: This patch eliminates the second allocation of a PageKey for the leaf node in the B-tree. Currently, BTreeScan has a variable which holds the page number of the current page. The page number is only needed for unlocking the scan when it's closed, and a new PageKey is generated (based on the page number) when a RecordHandle representing the scan lock row is allocated. The patch replaces the page number stored in BTreeScan with a PageKey which can be referenced directly by the RecordHandle, and thereby saves one object allocation. (Ideally, I think one would rather reuse the RecordHandle for the scan lock row since that would implicitly reuse the PageKey as well.)

getPage.diff: This patch eliminates one of the allocations of PageKey objects for the data page. It adds a getPage(PageKey) method to the ContainerHandle interface and looks up pages using the PageKey instead of PageKey.getPageNumber() + regeneration of the PageKey.

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