db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] Created: (DERBY-3843) enhance SYSCS_INPLACE_COMPRESS_TABLE to better handle overflow rows and overflow columns
Date Mon, 18 Aug 2008 17:01:44 GMT
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
    Affects Versions: 10.1.1.0
            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.


Mime
View raw message