[EMAIL PROTECTED] wrote:
Quoting Howard Chu <[EMAIL PROTECTED]>:
From: [EMAIL PROTECTED]
Is the b-tree order factor static?
I don't know what that is. What do you mean?
The max number keys for node of b-tree.
If I choose the btree algorithm, can I tuning btree configuration ?
There are no configuration keywords provided for tuning these limits. In
BerkeleyDB there is a function for configuring the minimum number of keys per
node, but obviously the maximum depends entirely on your data size and the
database page size.
There are at least three different cases to consider in back-bdb. In two of
those cases we use the default 4096 byte page size (dn2id, attribute
indices). In the third case (id2entry) we use a 16384 byte page size.
In a typical attribute index the keys and data items are 4 bytes. So each 4K
page can contain 512 items. As such, indices tend to have very flat, compact
trees, and never use overflow pages.
For the dn2id index the keys are the entry DNs, and so they vary in length.
The data items are still just 4 byte entry IDs. Typically there's many items
per page, and no overflow pages. However, there's a much larger number of
data items in the dn2id index, so this tree tends to be taller. In back-hdb
since we only store RDNs and not DNs, and we don't store subtree or onelevel
indices, the dn2id index is much more compact.
The id2entry database stores the actual entry data. We chose 16384 bytes
because it will easily accomodate most whitepages entries without needing any
overflow pages.
Tuning the minimum key count for the attribute indices or for the dn2id index
is pointless - the default minimum is 2 and we are pretty much guaranteed to
get at least a few hundred keys per page just by the nature of the data.
I.e., the minimum of 2 is irrelevant because we will always be well above the
minimum.
Tuning the minimum key count for the id2entry database isn't a good idea
either. Raising it much above 4 would cause lots of overflow pages to be used
for typical data, and overall performance would suffer.
So, to sum up - no, you can't tune this, nor should you even try.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
---
You are currently subscribed to [email protected] as: [EMAIL PROTECTED]
To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the
SUBJECT of the message.
