Description
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.
Attachments
Issue Links
- is related to
-
DERBY-5356 Tracking for Derby space reclamation issues
-
- Open
-
-
-
- Open
-