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.
