B-tree scanner index compression levels and transaction processing performance
B-tree scanner threads compress indexes by merging two partially used index pages if the amount of data on those pages is below the level that is specified by the compression option. You can set the compression level to control the amount of I/O required to find and load data.
B-tree scanner threads look for index pages that can be compressed because they are below the specified level. The B-tree scanner can compress index pages with deleted items and pages that do not have deleted items.
By default, a B-tree scanner compresses at the medium level. The following table provides information about the performance benefits and trade-offs if you change the compression level to high or low.
Compression Level | Performance Benefits and Trade-offs | When to Use |
---|---|---|
Low | The low compression level is beneficial for an index that is expected to grow quickly, with frequent B-tree node splits. When the compression level is set to low, the B-tree index will not require as many splits as indexes with medium or high compression levels, because more free space remains in the B-tree nodes. | You might want to change the compression level to low if you expect an index to grow quickly with frequent splits. |
High | In general, if an index is read-only or 90 percent
of it is read-only, the high compression level is beneficial because
searching for data will require fewer pages (and less I/O) to traverse.
Examples might be indexes that do not have frequent changes or indexes
undergoing batch (block) delete operations. Using high level of compression also means a performance trade-off, because it takes more I/O to compress the index more aggressively. Select operations will have less I/O when the compression level is high. |
You might want to change the compression
level to high under these circumstances:
|
If you do not need to change the compression level to high or low,
set the compression option of the BTSCANNER configuration parameter
to med
or default
.
Index Compression and the Index Fill Factor
In addition to the compression option that specifies when to attempt to join two partially used pages, you can use the FILL FACTOR configuration parameter to control when to add new index pages. The index fill factor, which you define with the FILLFACTOR configuration parameter or the FILLFACTOR option of the CREATE INDEX statement, is a percentage of each index page that will be filled during the index build.