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-2878) Scan protection handle could be cached in BasePage
Date Wed, 18 Jul 2007 09:06:05 GMT

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


Mime
View raw message