1<!--$Id: bt_minkey.so,v 10.14 2000/03/18 21:43:08 bostic Exp $--> 2<!--Copyright (c) 1997,2008 Oracle. All rights reserved.--> 3<!--See the file LICENSE for redistribution information.--> 4<html> 5<head> 6<title>Berkeley DB Reference Guide: Minimum keys per page</title> 7<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> 8<meta name="keywords" content="embedded,database,programmatic,toolkit,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++"> 9</head> 10<body bgcolor=white> 11<table width="100%"><tr valign=top> 12<td><b><dl><dt>Berkeley DB Reference Guide:<dd>Access Methods</dl></b></td> 13<td align=right><a href="/am_conf/bt_prefix.html"><img src="/images/prev.gif" alt="Prev"></a><a href="/toc.html"><img src="/images/ref.gif" alt="Ref"></a><a href="/am_conf/bt_recnum.html"><img src="/images/next.gif" alt="Next"></a> 14</td></tr></table> 15<p align=center><b>Minimum keys per page</b></p> 16<p>The number of keys stored on each page affects the size of a Btree and 17how it is maintained. Therefore, it also affects the retrieval and search 18performance of the tree. For each Btree, Berkeley DB computes a maximum key 19and data size. This size is a function of the page size and the fact that 20at least two key/data pairs must fit on any Btree page. Whenever key or 21data items exceed the calculated size, they are stored on overflow pages 22instead of in the standard Btree leaf pages.</p> 23<p>Applications may use the <a href="/api_c/db_set_bt_minkey.html">DB->set_bt_minkey</a> method to change the minimum 24number of keys that must fit on a Btree page from two to another value. 25Altering this value in turn alters the on-page maximum size, and can be 26used to force key and data items which would normally be stored in the 27Btree leaf pages onto overflow pages.</p> 28<p>Some data sets can benefit from this tuning. For example, consider an 29application using large page sizes, with a data set almost entirely 30consisting of small key and data items, but with a few large items. By 31setting the minimum number of keys that must fit on a page, the 32application can force the outsized items to be stored on overflow pages. 33That in turn can potentially keep the tree more compact, that is, with 34fewer internal levels to traverse during searches.</p> 35<p>The following calculation is similar to the one performed by the Btree 36implementation. (The <b>minimum_keys</b> value is multiplied by 2 37because each key/data pair requires 2 slots on a Btree page.)</p> 38<blockquote><pre>maximum_size = page_size / (minimum_keys * 2)</pre></blockquote> 39<p>Using this calculation, if the page size is 8KB and the default 40<b>minimum_keys</b> value of 2 is used, then any key or data items 41larger than 2KB will be forced to an overflow page. If an application 42were to specify a <b>minimum_key</b> value of 100, then any key or data 43items larger than roughly 40 bytes would be forced to overflow pages.</p> 44<p>It is important to remember that accesses to overflow pages do not perform 45as well as accesses to the standard Btree leaf pages, and so setting the 46value incorrectly can result in overusing overflow pages and decreasing 47the application's overall performance.</p> 48<table width="100%"><tr><td><br></td><td align=right><a href="/am_conf/bt_prefix.html"><img src="/images/prev.gif" alt="Prev"></a><a href="/toc.html"><img src="/images/ref.gif" alt="Ref"></a><a href="/am_conf/bt_recnum.html"><img src="/images/next.gif" alt="Next"></a> 49</td></tr></table> 50<p><font size=1>Copyright (c) 1996,2008 Oracle. All rights reserved.</font> 51</body> 52</html> 53