[Blocks in General] [Database Blocks] [Index Blocks] [Moving Forward]

Progress has a facility for us to adjust the block size that is used to store data within the database. Historically this was always controlled by Progress typically, 1k for Unix and 4k for NT.

There are performance reasons for using larger block sizes but other issues exist.

Blocks in General

Every block within Progress is issued with a header. This header contains various bits of information about which block it is, when it was last backed up, the sort of block that it is (data, index etc) as well as an offset table. All this information removes bytes that would of normally been available to store our data. The total number of bytes used by this header is 80 bytes for a 4k database block and 144 bytes for an 8k database block.

Database Blocks A block in Progress can store a number of records. The quantity that can be stored is dependent on the block size. So if we are using a 4k database block size then we can store only 32 records within it.

Lets take an example file, the customer file from the Progress sports database. We can find the average record size for this file by running the 'proutil sports -C tabanalys' utility. The output is shown below.



With an average record size of 137 bytes, 32 records will require 4384 bytes. The customer record will therefor fill entirely a block making full use of the available space.

However, if we take the 'state' file, it has an average record size of only 22 bytes, 32 records will require only 704 bytes. This means that all database block sizes will have space remaining (see figure C).



The amount of wastage increases with the database block size that is being used. If you take another quick look at Figure B above you will see that the majority of files have quite small average record sizes. So across the whole database there will be much wastage.

If we take the master sports database and create a database for each database block size we can then use this information to look at wastage. This is a very small database but hopefully it proves the point. Using a 4k or an 8k database approximately doubles the amount of space that Progress requires to store the data compared to a 1k database block size. However this should not be the only factor in deciding which block size to use.





Progress is more efficient at reading blocks from disk when the block size of the database matches or is a multiple of the file system block size. If you were to use a 1k block size on top of a 4k file system. Then Progress would have to request 4 blocks to read 4k worth of information. If Progress had matched the file system block size, then a single read request would of read the 4k block in one chunk.

Changing the block size will also affect how the Progress buffer pool is managed. The setting set for the Buffer Pool is measured in Blocks. If you change from a 1k block size to a 4k block size then you need to devide your current 'B' setting by four so that you still use the same amount of memory. If you do not do this then Progress will attempt to claim four times more memory than before.

Index Blocks

Each index block contains index information for only one index. The indexes are compressed so a larger block size allows the index compression algorithm to work more efficiently. As more information is stored in the larger index blocks, this provides a performance benefit as each request of an index block causes Progress to read the index entries into memory. More elements can then be processed before requiring to read the next block from disk.

Moving Forwards

Version 9 offers the ability for us to specify how many records we wish to store in a block thereby reducing this wastage to nearly nothing. We can therefore locate tables with a small average record size into a specific storage area, adjusting the number of records per block as required and do the same for large records. This will significantly reduce the wastage and therefore the physical size of the database.

For more information on storage areas please see previous article publish in 'Progress User Group Newsletter - Winter 1999'

© Copyright Proxcom Limited 1999 - All Rights Reserved

[Top] [Blocks in General] [Database Blocks] [Index Blocks] [Moving Forward]