Kbase P169119: Are there any extra overhead on records with 64 bits rowid, except for the addressing bits?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
7/2/2010 |
|
Status: Unverified
GOAL:
Are there any extra overhead on records with 64 bits rowid, except for the addressing bits?
GOAL:
Overhead considerations with 64 bit rowid compared to 32 bit rowid
FACT(s) (Environment):
All Operating Systems
Progress 9.X
OpenEdge 10.x
FIX:
The important thing about the 64-bit rowids is that it eliminates the 2 billion row fragment per storage area limit. This 2 billion limit is theoretical and is further reduced if:
- some of the blocks in the area are index blocks. Each of those consumes the same number of rowids as the maximum-rows-per block setting. Those rowids are not available for use by rows.
- if a full block contains fewer row fragments than the maximum-rows-per-block setting the remaining rowids can't be used. This happens when the row size is larger than the rows-per-block allows for.
Eliminating the 2 billion limit means:
- you don't have to worry about reaching the limit for the storage area and not being able to add anymore data.
- you don't have to worry about wasting rowids due to row size not matching the area's maximum-rows-per-block setting.
Therefore, the value you choose for maximum-rows-per-block is no longer critical. In general 128 is a good value unless you have a special case of very small rows. For larger rows some rowids will be wasted but it doesn't matter anymore.
Row storage overhead
====================
The overhead is approximately as follows:
Assumptions:
Block size 8192
maximum rows per block 128
create limit 300
all directory entries used
Block Overhead:
Type ii block header 64
RM block header ~ 12
Row directory (128 entries) 256
*** Total block overhead -332
Space available 7860
Create limit -300
Space available for rows 7560
Per row overhead ~ 15
*** 128 row overhead -1920
Space for rows after overhead 5640
So that means that 128 rows of 44 bytes each would fit, leaving the 300 bytes free for the create limit. A similar calculation for 64 rows per block means you could fit 64 rows of 109 bytes each.
For 64-bit rowids, the overhead is the same with this exception: when rows are fragmented, then each fragment has a rowid for the next fragment and these could be larger.