Table C (File architecture): Difference between revisions
mNo edit summary |
No edit summary |
||
| Line 3: | Line 3: | ||
RANGE attributes.</p> | RANGE attributes.</p> | ||
<p>This page discusses the architecure underlying Table C. For information on monitoring, tuning and performance issues, refer to [[ | <p>This page discusses the architecure underlying Table C. For information on monitoring, tuning and performance issues, refer to [[Tuning the Hash Index]]. | ||
== Overview == | == Overview == | ||
<p> 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.</p> | <p> 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.</p> | ||
<p> Any time a field | <p> Any time a field (whether preallocated or a [[Field Value Pairs (File Architecture)|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.</p> | ||
<p>New KEY values require only two slots in Table C for an initial creation (one Property and one Segment entry). If the file size | <p>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 | ||
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 | 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 | rate dependent upon the level and nature of update activity, the number of slots | ||
used increases. | used increases.</p> | ||
| Line 20: | Line 19: | ||
<p>Because of the hashed nature of the contents, Table C may not be increased dynamically. Any changes must be done via a [[File Reorganization and Table Compaction|reorganization]].</p> | <p>Because of the hashed nature of the contents, Table C may not be increased dynamically. Any changes must be done via a [[File Reorganization and Table Compaction|reorganization]].</p> | ||
== Table C Page Structure == | |||
<p>Every Table C page is composed of a series of 7 byte hash cells (a total of 877 per page). It also contains 5 bytes used to track 'spills' (cases where the entry can not be placed on the page that the field / value hashes to).</p> | |||
<p>The hash cells contain one of two types of entry: Prperty, and Segment.</p> | |||
== Property Entries == | == Property Entries == | ||
<p>The starting point of a chain.</p> | <p>The starting point of a chain.</p> | ||
<p>When reading or updating a hash index, this is the location the field / value hashes in to. From there, the chain of segment entries are read.</p> | |||
| Line 28: | Line 36: | ||
== Segment Entries == | == Segment Entries == | ||
<p>Chained from the Property Entry are one or more segment entries (see the definition of segment which follows).</p> | |||
<p>In the segment entries, there are two possible references to record(s):</p> | |||
* 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 [[#Table D (File Architecture) List and Bit Map pages|list or bitmap page]]. | |||
It is quite possible that, for a particular field / value, some of the segment pointers will directly point to records, others will point to [[#Table D (File Architecture) List and Bit Map pages|list / bitmap pages]] and some segments, where no records will have the value for this field will not have an occurrence in the chain at all.</p> | |||
=== Segment definition === | |||
<p>A segment is a set of 49152 base record slots. This 'magic' number comes from the number of bits which fit on a Model 204 page (see [[#Table D (File Architecture)#List and Bit Map Pages|List and Bit Map pages]].</p> | |||
[[Category:File architecture]] | [[Category:File architecture]] | ||
Revision as of 21:50, 2 May 2013
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 Tuning the Hash Index.
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 (whether preallocated or 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.
Table C Page Structure
Every Table C page is composed of a series of 7 byte hash cells (a total of 877 per page). It also contains 5 bytes used to track 'spills' (cases where the entry can not be placed on the page that the field / value hashes to).
The hash cells contain one of two types of entry: Prperty, and Segment.
Property Entries
The starting point of a chain.
When reading or updating a hash index, this is the location the field / value hashes in to. From there, the chain of segment entries are read.
Segment Entries
Chained from the Property Entry are one or more segment entries (see the definition of segment which follows).
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, some of the segment pointers will directly point to records, others will point to list / bitmap pages and some segments, where no records will have the value for this field will not have an occurrence in the chain at all.
Segment definition
A segment is a set of 49152 base record slots. This 'magic' number comes from the number of bits which fit on a Model 204 page (see List and Bit Map pages.