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