db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3843) enhance SYSCS_INPLACE_COMPRESS_TABLE to better handle overflow rows and overflow columns
Date Tue, 18 Nov 2008 22:37:44 GMT

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

Kathey Marsden updated DERBY-3843:

    Component/s: Store

> enhance SYSCS_INPLACE_COMPRESS_TABLE to better handle overflow rows and overflow columns
> ----------------------------------------------------------------------------------------
>                 Key: DERBY-3843
>                 URL: https://issues.apache.org/jira/browse/DERBY-3843
>             Project: Derby
>          Issue Type: Improvement
>          Components: Store
>    Affects Versions:
>            Reporter: Mike Matrigali
> Currently SYSCS_INPLACE_COMPRESS_TABLE code executes at the access level.  It only interacts
with "user" level head pages, moving
> those rows around during the defragment phase to try and free up pages at the end of
the file which then can be returned to the operatiing system.   Only pages at the end of the
file can be returned to the operating system.  
> It does not do anything with the "child" chained pages of either overflow rows or overflow
columns.  So if one of these rows exists at the 
> end of the file then space will not be returned to the OS.  The function will reclaim
all the deleted space and make it available for subsequent
> inserts into the existing table, but the space will not be returned to the OS.
> There are at least 2 challenges to implementing such a feature.  First the current implementation
just does not have access to the overflow chains.  So the choice would be to transmit more
info up from raw store to store or to move the space stuff down into raw store.
> Second an implmentation that comes to mind is just to scan backward in the file looking
for these pieces.  But there are no "backward"
> pointers in an overflow chain so it is impossible to tell from a child piece what it's
parent is.  So code can't just move the child piece and 
> make a single pointer fixup.  Without a format change the work all has to be top down.
> All the following can result in a situation affected by this issue:
> o blob/clob column which is longer than a page
> o any row that is in total longer than a page
> o any row/column that is updated subsequent to insert and expands the space of the row/column
may cause this.  It depends on how
>     much is expanded and what the state of the existing page is, including "reserved
space".  As an example imagine a table with no
>    reserved space.  Derby will attempt to pack rows as tightly as possible on a base
page, and once on a base page it will not move the
>    head of the row off this page unless a normal compress is done (row level locking
depends on the head location not moving to use
>    as the locking key).  Then a subsequent update expands the row in some way, the code
will overflow this row which may in fact be
>    relatively short, to another page leaving the head on the original page.

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

View raw message