|
|
|
COMPATIBILITY KEEP_EMPTY_NODE_ON_READ
Performance issues have been reported due to a recent code change that unexpectedly caused situations where empty nodes could remain in an index until someone modified that node or until the index was rebuilt. Historically, empty index nodes have been processed by the FairCom Database Engine through an "index node pruning" strategy. When the number of keys in the node is zero, the node is added to a "delete node queue" to be removed by a background thread.
The root cause of this issue involves a situation where node pruning could fail if a table lock was outstanding, leaving empty nodes in indexes and causing performance issues. If a node was in this unusual empty state (due to a failed delete node pruning operation, or a server crash), it could remain in that state until someone modified that node or the index was rebuilt. This revision adds a request to prune a node whenever an empty node is read from disk, which should alleviate this problem.
FairCom DB's delete-node thread prunes empty nodes from index files in the background. It densely packs key data for optimal index performance. To prevent index corruption, it runs during idle times and opens the index file exclusively, which prevents external processes from opening it.
To disable the "index node prune" feature, for example to allow an external process to open an index file, use the following keyword:
COMPATIBILITY NO_DELNOD_QUEUE
The above keyword prevents the delete-node thread from running, which prevents automatic index optimization, however, it allows external processes to open the index file.
Another keyword, COMPATIBILITY KEEP_EMPTY_NODE_ON_READ, prevents empty nodes read from disk being added to the delete queue. This is the V2/V11 and earlier behavior.
See also
