Table C (File architecture): Difference between revisions

From m204wiki
Jump to navigation Jump to search
No edit summary
No edit summary
 
(23 intermediate revisions by 6 users not shown)
Line 1: Line 1:
<p>Table C is a hashed table divided into entries of seven bytes each. Table C
<p>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
entries store index information for fields that have the <var>KEY</var> or the <var>NUMERIC
RANGE attributes.</p>
RANGE</var> attribute.</p>


== Overview ==
<p>This page discusses the architecture underlying Table C. For information on monitoring, tuning, and performance issues, refer to [[Tuning the hash index]].</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 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>
==Overview==
<p>  
Model 204 creates a chain of entries in Table C for each value stored in a <var>KEY</var> field, and several chains of entries for each value stored in a <var>NUMERIC RANGE</var> field.</p>


<p>The chain is read (or created) to find the Segment Entry covering the record being updated.</p>  
<p> Any time a field (whether preallocated or a [[Field value pairs (File architecture)|field value pair]]) that has the <var>KEY</var> or <var>NUMERIC RANGE</var> attribute 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>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>New <var>KEY</var> 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  [[File size calculation in detail#Computing the file size multiplier (N)|Computing the file size multiplier (N)]]) is greater than 1 (signifying the number of segments in the file), <var>KEY</var> 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.</p>


== Property Entries ==
<p>The chain is read (or created) to find the Segment entry covering the record being updated.</p>  
<p>The starting point of a chain.</p>


== Segment Entries ==
<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 cannot be placed on the page to which the field/value hashes).</p>


== Identifying Record(s) From the Chain ==
<p>The hash cells contain one of two types of entry: property and segment.</p>


In the segment entries, there are two possible references to record(s):
==Property entries==
<p>
A property entry is the starting point of a chain. When reading or updating a hash index, this is the location to which the field/value hashes in. From there, the chain of segment entries are read.</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).
==Segment entries==
* Otherwise, the segment will point to a [[#Table D (File Architecture) List and Bit Map pages|list or bitmap page]].
<p>
Chained from the property entry are one or more segment entries (see the definition of segment, which follows).</p>


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 [[#Table D (File Architecture) List and Bit Map pages|list / bitmap pages]].  
<p>Segment entries have two possible references to records:</p>
<ul>
<li>If the segment contains one and only one record with that combination of field and value, there is a direct pointer to the record (the [[Table B (File architecture)#Internal Record Number|Internal Record Number (IRN)]] is physically stored in the Table C entry).


<li>Otherwise, the segment points to a [[Table D (File architecture)#List and bitmap pages|list or bitmap page]].
</ul>


It is quite possible that, for a particular field/value, some of the segment pointers directly point to records; others point to list or bitmap pages; and some segments, where no records have the value for this field, have no occurrence in the chain at all. 


[[Category:File Architecture and Management]]
===Segment definition===
[[Category:File Architecture]]
<p>
A segment is a set of 49152 base record slots. This "magic" number comes from the number of bits that fit on a Model&nbsp;204 page (see [[Table D (File architecture)#List and bitmap pages|List and bitmap pages]]).</p>
 
[[Category:File architecture]]

Latest revision as of 22:29, 13 April 2015

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 attribute.

This page discusses the architecture 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 attribute 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)) is greater than 1 (signifying the number of segments in the file), 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 cannot be placed on the page to which the field/value hashes).

The hash cells contain one of two types of entry: property and segment.

Property entries

A property entry is the starting point of a chain. When reading or updating a hash index, this is the location to which the field/value hashes in. 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).

Segment entries have two possible references to records:

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

It is quite possible that, for a particular field/value, some of the segment pointers directly point to records; others point to list or bitmap pages; and some segments, where no records have the value for this field, have no 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 that fit on a Model 204 page (see List and bitmap pages).