G
gus bjorklund
Guest
A: validation There is /no/ additional overhead required to validate a unique index entry. The way it works is this: When you execute a CREATE statement, we make a copy of the table's template records and put it into the record buffer. If there are any today or now fields, we fill in those values. the record buffer now has all the initial field values. At this point, the record is not in the database. Once your code as given values to all the fields that are the key components of a unique index (or the end of the assign statement that does so has been reached), we validate the unique key or keys To do this, we send the record to the database and then create the requisite index entry or entries. at this point the index entry creation may fail due to a uniqueness error. if it doesn’t fail, then the index entry is complete and we can move on. the only difference for a nonunique index is that there can be no uniqueness error. The only difference the validation makes is that we may have to send the record to the database earlier than if we didn’t need to validate. everything else is the /same/ with or without unique index key validation. B: index compression The compression is very much better than that. we use 3 types of compression in the indexes. 0) in the levels above the leaf, we remove redundant trailing bytes, keeping only as much of the index entry as we need to find the leftmost entry in the next lower level. for example, if the index is on last name, the first entry might be “adams” followed by the rest of the a's and then there might be “barry". at the level above the leaf we might need only “a” and “b” instead of the full name. 1) we discard the leading part of an index entry when all or part of it is the same as the preceding entry, replacing it with a count of the number of bytes that were discarded. for example, we might have the key values fred100000001 fred100000002 bob100000003 bob100000004 after compression it will look like this fred100000001 2 bob100000003 4 2) when the key is nonunique, there may be multiple rowids for the same key value. If so, we can retain a single copy of the key value and then list the rowids associated with the key. we also compress the rowid list. we can’t do that for a unique index since there will be only one rowid per entry.
Continue reading...
Continue reading...