Uploaded image for project: 'Derby'
  1. Derby
  2. DERBY-3843

enhance SYSCS_INPLACE_COMPRESS_TABLE to better handle overflow rows and overflow columns



    • Improvement
    • Status: Open
    • Major
    • Resolution: Unresolved
    • None
    • Store


      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.


        Issue Links



              Unassigned Unassigned
              mikem Mike Matrigali
              0 Vote for this issue
              0 Start watching this issue