Øystein Grøvlen wrote:
"MM" == Mike Matrigali <[EMAIL PROTECTED]> writes:
MM> Øystein Grøvlen wrote:
>>>>>>> "MM" == Mike Matrigali <[EMAIL PROTECTED]> writes:
>>
>>
MM> It is only stable while some sort of stable table intent lock is held.
MM> Rows can move during a compress table operation.
>>
>> I understand, when a record is moved to another page, its RecordId
>> will change. Is this the only case where a RecordId will change? If
>> yes, I would think one could solve the problem for insensitive result
>> sets by invalidating open result sets when an underlying table is
>> compressed.
>>
>> Some questions to how compression works:
>> - Will RecordIds ever be reused or will the sequence number continue to
>> increase?
MM> Derby now supports 2 different compression techniques, basically one
MM> offline and one online.
MM> SYSCS_UTIL.SYSCS_COMPRESS_TABLE() basically copies all rows from one
MM> table to another, so recordId's may be reused. This requires table
MM> level locking and so is effectively offline.
Do not the new version of the table get a new container key? If yes,
I would think that recordId's are not reused since container key is
part of the record id.
That is an interesting point. I think the correct answer depends on how
one is using the row location. Currently the on disk format of the only
current implementation of a row location is done by HeapRowLocation and
it only stores a page and record number. While logically the record id
includes it's container, the current usage only requires the page and
record id. This was a significant space savings in indexes, but does
restrict all rows in a given index to point to a single container - not
a problem with current implementation. The in-memory versions of
HeapRowLocation do associate each with a single container for locking.
MM> SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE() moves records within the
MM> same table, and will not reuse RecordId's, but a given record can
MM> definitely change RecordId. This requires row locks
MM> for purged/moved rows for most of it's work. Giving back space to
MM> OS requires short time table level lock.
Good, I was not aware that there was an online version of compress.
>> - How do you ensure that the old RecordIds are not encountered
>> during recovery? Does the compression include a checkpoint?
MM> Neither really does anything special to stop old recordId's from
MM> being encountered during recovery. With offline redo recovery of
MM> old table is basically a drop table so either the table is there
MM> and we drop it again, or the table is already dropped and we do
MM> nothing. In online it is the normal case of redo or a record delete
MM> or a record purge, in either case redo will either see a version of
MM> the page where it can redo the delete or purge or it will see from
MM> the version of the page that there is no work to do.
