Table C (File architecture)

From m204wiki
Revision as of 04:53, 5 April 2013 by Rob (talk | contribs)
Jump to navigation Jump to search

Table C is a hashed table divided into entries of seven bytes each. Table C entries store index information for fields that have the KEY or the NUMERIC RANGE attributes.

This page discusses the architecure underlying Table C. For information on monitoring, tuning and performance issues, refer to managing Table C.

Overview

Model 204 creates a chain of entries in Table C for each value stored in a KEY field and several chains of entries for each value stored in a NUMERIC RANGE field.

Any time a field value pair that has the KEY or NUMERIC range attributes is added to a record, the hashing algorithm is used to find a Property Entry. If it is not found it is created.

New KEY values require only two slots in Table C for an initial creation (one Property and one Segment entry). If the file size multiplier (discussed in “Computing the file size multiplier (N)” on page 79) is greater than 1, KEY values might require more than two slots. Therefore, at a rate dependent upon the level and nature of update activity, the number of slots used increases.

The chain is read (or created) to find the Segment Entry covering the record being updated.

Because of the hashed nature of the contents, Table C may not be increased dynamically. Any changes must be done via a reorganization.

Property Entries

The starting point of a chain.


Segment Entries

Segment definition

Identifying Record(s) From the Chain

In the segment entries, there are two possible references to record(s):

  • If, in that segment, there is one and only one record, with that combination of field and value, there is a direct pointer to the record (the IRN is physically stored in the Table C entry).
  • Otherwise, the segment will point to a list or bitmap page.

It is quite possible that, for a particular field value pair, some of the segment pointers will point to records, and others will point to list / bitmap pages.