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

Knut Anders Hatlen updated DERBY-2878:
--------------------------------------

    Attachment: derby-2878-3a.diff

Attaching a new and simpler patch (3a) which replaces patch 3. The new patch 
only makes these changes:

  1) replaces the field current_scan_pageno (a long) in BTreeRowPosition with 
current_scan_protectionHandle (a RecordHandle which is cached in BasePage)
  2) changes the signature of BTreeLockingPolicy.unlockScan() to take a 
RecordHandle
  3) removes unused method OpenBTree.makeRecordHandle()

With this patch, a B-tree scan does not allocate any protection record handle 
if the leaf pages it visits are in the page cache and have been scanned before. 
Derbyall and suites.All passed with the new patch.

> Scan protection handle could be cached in BasePage
> --------------------------------------------------
>
>                 Key: DERBY-2878
>                 URL: https://issues.apache.org/jira/browse/DERBY-2878
>             Project: Derby
>          Issue Type: Improvement
>          Components: Performance, Store
>    Affects Versions: 10.4.0.0
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: derby-2878-1.diff, derby-2878-1.stat, 
> derby-2878-1b.diff, derby-2878-2.diff, derby-2878-3.diff, derby-2878-3.stat, 
> derby-2878-3a.diff
>
>
> Each time a leaf node in a B-tree is visited in an index scan, a scan 
> protection row is locked and unlocked. Both the lock operation and the unlock 
> operation will allocate a new RecordId object representing the scan 
> protection row (the unlock operation additionally allocates a PageKey object 
> for the RecordId). Since the scan protection handle created will be identical 
> (seen from equals()) each time it is created for a page, it would make sense 
> to cache it in BasePage. Then we only need to allocate the protection handle 
> for a page once for as long as it stays in the page cache. This would save 
> three object allocations per single-record lookup via index.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to